[PATCH] ARM: dts: am335x-evmsk: enable USB1
From: Yegor Yefremov
Enable second USB channel and set it into 'host' mode.
Signed-off-by: Yegor Yefremov
---
arch/arm/boot/dts/am335x-evmsk.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 486880b..40a66bd 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -342,9 +342,18 @@
status = "okay";
};
+ usb-phy@47401b00 {
+ status = "okay";
+ };
+
usb@47401000 {
status = "okay";
};
+
+ usb@47401800 {
+ status = "okay";
+ dr_mode = "host";
+ };
};
&epwmss2 {
--
1.7.7
--
To unsubscribe from this list: send the line "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 v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings
On 27/02/14 18:54, Philipp Zabel wrote:
>> - One IPU enabled, one disabled: nothing special here, just set the
>> other IPU to status="disabled" in the DT data. The driver for the
>> enabled IPU would register the required DRM entities.
>
> that should work. Let the enabled IPU create the imx-drm platform device
> on probe, parse the device tree and ignore everything only hanging off
> of the disabled IPU.
I think you misunderstood me a bit.
What I meant is that there's no need for imx-drm device at all, neither
in the DT data or in the kernel side.
There'd just be the DT nodes for the IPUs, which would cause the IPU
platform devices to be created, and a driver for the IPU. So just like
for any other normal platform device.
In the simplest cases, where only one IPU is enabled, or the IPUs want
to be considered as totally independent, there'd be nothing special. The
IPU driver would just register the drm entities.
> [Reordering a bit...]
>> - Two IPUs in combined mode:
>>
>> Pick one IPU as the master, and one as slave. Link the IPU nodes in DT
>> data with phandles, say: master=<&ipu1> on the slave IPU and
>> slave=<&ipu0> on the master.
>>
>> The master one will register the DRM entities, and the slave one will
>> just do what the master says.
>
> That might work, too. Just let the each IPU scan the graph and try to
> find the imx-drm master before creating the imx-drm platform device.
> The first IPU fill find no preexisting master and create the imx-drm
> platform device as above, adding the other IPU as well as the other
> components with component_master_add_child. It just has to make sure
> that the other IPU is added to the list before the encoders are.
>
> The second IPU will scan the graph, find a preexisting master for the
> other IPU node, register its component and just wait to be bound by the
> master.
Here the slave IPU doesn't need to scan the graph at all. It just needs
to make itself available somehow to the master. Maybe just by exported
functions, or registering itself somewhere.
Only the master IPU will scan the graph, and as all the entities are
connected to the same graph, including the slave IPU, the master can
find all the relevant nodes.
>> - Two IPUs as separate units: almost the same as above, but both would
>> independently register the DRM entities.
>
> Here the second IPU would not be connected to the first IPU via the
> graph - it would not find a preexisting imx-drm device when scanning its
> graph and create its own imx-drm device just like the first IPU did.
> As a result there are two completely separate DRM devices.
I understood that that would be the idea, two separate, independent DRM
devices. Like two graphics cards on a PC.
> That being said, this change could be made at any time in the future,
> in a backwards compatible fashion, by just declaring the imx-drm node
> optional and ignoring it if it exists.
Yes, I agree.
And I don't even know if the master-slave method I described is valid,
although I don't see why it would not work. The master
"display-subsystem" DT node does make sense to me in cases like this,
where the IPUs need to be driven as a single unit.
> Did anybody propose such a generic term? How about:
>
> -imx-drm {
> - compatible = "fsl,imx-drm";
> - ports = <&ipu1_di0>, <&ipu1_di1>;
> -};
> +display-subsystem {
> + compatible = "fsl,imx-display-subsystem";
> + ports = <&ipu1_di0>, <&ipu1_di1>;
> +};
That sounds fine to me.
I wonder how it works if, say, there are 4 IPUs, and you want to run
them in two pairs. In that case you need two of those display-subsystem
nodes. But I guess it's just a matter of assigning a number for them
with 'regs' property, and making sure the driver has nothing that
prevents multiple instances of it.
>>> If this wasn't the case, we wouldn't even attempt to describe what devices
>>> we have on which I2C buses - we'd just list the hardware on the board
>>> without giving any information about how it's wired together.
>>>
>>> This is no different - however, it doesn't have (and shouldn't) be
>>> subsystem specific... but - and this is the challenge we then face - how
>>> do you decide that on one board with a single zImage kernel, with both
>>> DRM and fbdev built-in, whether to use the DRM interfaces or the fbdev
>>> interfaces? We could have both matching the same compatible string, but
>>> we'd also need some way to tell each other that they're not allowed to
>>> bind.
>>
>> Yes, that's an annoying problem, we have that on OMAP. It's a clear sign
>> that our video support is rather messed up.
>>
>> My opinion is that the fbdev and drm drivers for a single hardware
>> should be exclusive at compile time. We don't allow multiple drivers for
>> single device for other subsystems either, do we? Eventually we should
>> have only one driver for one hardware device.
>>
>> If that's not possible, then the drivers in question could have an
>> option to enable or disable themselves, passed via th
Re: [PATCH V2 1/3] dt: palmas: support IRQ inversion at the board level
On Thu, Feb 27, 2014 at 02:35:42PM -0700, Stephen Warren wrote: > On 02/27/2014 02:02 PM, Graeme Gregory wrote: > >> +- ti,irq-externally-inverted : If missing, the polarity of the Palmas IRQ > >> + output should be set to the opposite of the polarity indicated by the > >> IRQ > >> + specifier in the interrupts property. If absent, the polarity should be > >> + configured to match. This allows the representation of an inverter > >> between > >> + the Palmas IRQ output and the interrupt parent's IRQ input. > > This has got to be the wrong way to do things, all this leads to is every > > device doing this property in its own way and having totally inconsistent > > properties all meaning the same thing. > > If there is some other hardware inverting lines then there should be > > a generic binding for this in DT. This is not describing the palmas hardware > > but some external object to the palmas. > I'd be fine with removing the "ti," vendor prefix from the property > name, and promoting it to be a cross-device standard. > I'm not sure that many devices will need this though; most don't have > configurable output polarity. Still, I guess that shouldn't stop us from > creating standards for the cases where it is needed. It's really common for PMICs and CODECs to be able to set any interrupt polarity at least. > If the DT reviewers can ack the concept, I'm happy to respin the patch > with the more generic property name. I'm not sure that renaming the property really deals with the concerns though since drivers still all need to manually add support for this, shouldn't there be an interrupt controller described in the DT which just chains on to the parent with the polarity inverted to do the impedence match? signature.asc Description: Digital signature
Re: [PATCH v3] hwspinlock/msm: Add support for Qualcomm MSM HW Mutex block
Hi Kumar,
I pulled this in to my 3.14 tree and gave it a spin. But I keep
hitting the case of unlock below telling me that someone else is
holding the lock.
On Wed, Aug 14, 2013 at 12:09 PM, Kumar Gala wrote:
[...]
> +
> +static int msm_hwspinlock_trylock(struct hwspinlock *lock)
> +{
> + void __iomem *lock_addr = lock->priv;
> +
> + writel_relaxed(SPINLOCK_ID_APPS_PROC, lock_addr);
You need some sort of barrier here; the caf code have a smp_mb() here,
inserting that solves the problem.
> +
> + return readl_relaxed(lock_addr) == SPINLOCK_ID_APPS_PROC;
> +}
> +
> +static void msm_hwspinlock_unlock(struct hwspinlock *lock)
> +{
> + u32 lock_owner;
> + void __iomem *lock_addr = lock->priv;
> +
> + lock_owner = readl_relaxed(lock_addr);
> + if (lock_owner != SPINLOCK_ID_APPS_PROC) {
> + pr_err("%s: spinlock not owned by us (actual owner is %d)\n",
> + __func__, lock_owner);
> + }
> +
> + writel_relaxed(0, lock_addr);
> +}
> +
Part of this I think this driver looks good, it would be nice to get
the last details cleaned up so we could get it into the tree.
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4] can: xilinx CAN controller support.
Hi Marc,
> -Original Message-
> From: Marc Kleine-Budde [mailto:m...@pengutronix.de]
> Sent: Wednesday, February 26, 2014 9:13 PM
> To: Appana Durga Kedareswara Rao; w...@grandegger.com; Michal Simek;
> grant.lik...@linaro.org; robh...@kernel.org; linux-...@vger.kernel.org
> Cc: net...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; devicetree@vger.kernel.org
> Subject: Re: [PATCH v4] can: xilinx CAN controller support.
>
> On 02/26/2014 03:46 PM, Appana Durga Kedareswara Rao wrote:
> > Hi Marc,
> >
> >
> >> -Original Message-
> >> From: Marc Kleine-Budde [mailto:m...@pengutronix.de]
> >> Sent: Wednesday, February 26, 2014 6:52 PM
> >> To: Appana Durga Kedareswara Rao; w...@grandegger.com; Michal Simek;
> >> grant.lik...@linaro.org; robh...@kernel.org;
> >> linux-...@vger.kernel.org
> >> Cc: net...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> >> linux- ker...@vger.kernel.org; devicetree@vger.kernel.org
> >> Subject: Re: [PATCH v4] can: xilinx CAN controller support.
> >>
> >> On 02/26/2014 02:07 PM, Appana Durga Kedareswara Rao wrote:
> This loop looks broken. Can you explain how it works.
>
> What it shoud do is:
> We have put (priv->tx_head - priv->tx_tail) CAN frames into the FIFO.
> This means at maximum there could be this amount of CAN frames
> which have been successfully transmitted. For every cycle in this
> while loop you
> should:
> a) check if a CAN frame has successfully been transmitted
> (as this CAN core uses a FIFO it should be "oldest")
> A read_reg() of some kind is missing in your loop.
> b) if needed, remove this event from the FIFO or
> mark the interrupt as done. Whatever you hardware needs.
> c) update your statistics
> d) Use can_get_echo_skb to push this frame into the networking
> stack
> e) As a CAN frame has been transmitted successfully, wake the
> tx_queue.
>
> > + while (priv->tx_head - priv->tx_tail > 0) {
> > + if (isr & XCAN_IXR_TXFLL_MASK) {
> > + priv->write_reg(priv, XCAN_ICR_OFFSET,
> > + XCAN_IXR_TXFLL_MASK);
> > + netif_stop_queue(ndev);
>
> Why do you stop the queue here? A CAN frame has successfully been
> transmitted, there should be room in the FIFO.
>
> > + break;
> > + }
> > + can_get_echo_skb(ndev, priv->tx_tail %
> > + priv->xcan_echo_skb_max_tx);
> > + priv->tx_tail++;
> > + }
> > +
> >>>
> >>> The below are the bit fields available for the Transmit FIFO.
> >>> 1) In the ISR(interrupt status register) Tx Ok interrupt and Tx
> >>> fifo full
> >> interrupt.
> >>> 2) in the SR(Status Register) Tx fifo full condition.
> >>>
> >>>
> >>> I am modifying the entire tx interrupt logic to like below.
> >>>
> >>> static void xcan_tx_interrupt(struct net_device *ndev, u32 isr) {
> >>> struct xcan_priv *priv = netdev_priv(ndev);
> >>> struct net_device_stats *stats = &ndev->stats;
> >>>
> >>> while (priv->tx_head - priv->tx_tail > 0) {
> >>> if (isr & XCAN_IXR_TXFLL_MASK) {
> >>> priv->write_reg(priv, XCAN_ICR_OFFSET,
> >>> XCAN_IXR_TXFLL_MASK);
> >>> break;
> >>> }
> >>> can_get_echo_skb(ndev, priv->tx_tail %
> >>> priv->xcan_echo_skb_max_tx);
> >>> priv->tx_tail++;
> >>> stats->tx_packets++;
> >>> netif_wake_queue(ndev);
> >>> can_led_event(ndev, CAN_LED_EVENT_TX);
> >>>
> >>> }
> >>
> >> You just need to wake the queue once.
> >
> > Ok
> >>
> >>> }
> >>>
> >>>
> >>> Are you Ok with the above logic?
> >>
> >> No, how can you tell how many frames have been transmitted?
> >
> > There is no register to read how many can frames are transmitted.
> > The only way to know Is by reading this parameter
> > (stats->tx_packets++;) through ip command
>
> stats->tx_packets is calculated in the above loop and the loop is
> broken. Let me illustrate the problem:
>
> - xmit is called 10 times in a row
> - this means you have 10 CAN frames in the TX FIFO
> - a single CAN frame gets transmitted
> - you get an interrupt
> - you enter the above routine and loop 10 times and echo the CAN frame
> back into the stack
>
> Now every application sees 10 transmitted packages, but there is only one
> transmitted. Every time you loop you have to check if the CAN frame has
> already been transmitted or not. Is that possible with the hardware?
The only way to know whether the TX packet is transmitted successfully
or not is by using the Tx Ok interrupt from the ISR.
This interrupt will come for every Tx Packet.
So I am thinking of ther
Re: [PATCHv1 1/2] rx51_battery: convert to iio consumer
On Thu, Feb 27, 2014 at 10:34:35PM +0100, Belisko Marek wrote: > Well I've tried and it's worse :). I got during booting: > [2.218383] ERROR: could not get IIO channel /battery:temp(0) > [2.224639] platform battery.4: Driver twl4030_madc_battery > requests probe deferral > Not sure if it's just error or warning but temp is always reported as > 0 (and also other values in sysfs). This is an error, which basically means, that twl4030-madc has not yet been loaded. Do you get proper values when you use the old madc API with the patchset applied? -- Sebastian signature.asc Description: Digital signature
[PATCH v4 8/9] devicetree: bindings: Document PM8921/8058 power keys
Document the power key found on PM8921 and PM8058 PMICs.
Cc:
Signed-off-by: Stephen Boyd
---
.../bindings/input/qcom,pm8xxx-pwrkey.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
b/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
new file mode 100644
index ..e124d9f33632
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
@@ -0,0 +1,39 @@
+Qualcomm PM8xxx PMIC Power Key
+
+PROPERTIES
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,pm8058-pwrkey"
+ "qcom,pm8921-pwrkey"
+- interrupts:
+ Usage: required
+ Value type:
+ Definition: the first interrupt specifies the key release interrupt
+ and the second interrupt specifies the key press interrupt.
+ The format of the specifier is defined by the binding
+ document describing the node's interrupt parent.
+
+- debounce:
+ Usage: optional
+ Value type:
+ Definition: time in microseconds that key must be pressed or release
+ for state change interrupt to trigger.
+
+- pull-up:
+ Usage: optional
+ Value type:
+ Definition: presence of this property indicates that the KPDPWR_N pin
+ should be configured for pull up.
+
+EXAMPLE
+
+ pwrkey {
+ compatible = "qcom,pm8921-pwrkey";
+ interrupt-parent = <&pmicintc>;
+ interrupts = <50 1>, <51 1>;
+ debounce = <15625>;
+ pull-up;
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 9/9] devicetree: bindings: Document PM8921/8058 vibrators
Document the vibration device found on PM8921 and PM8058 PMICs.
Cc:
Signed-off-by: Stephen Boyd
---
.../devicetree/bindings/input/qcom,pm8xxx-vib.txt| 16
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt
b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt
new file mode 100644
index ..dca1b8872cf1
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt
@@ -0,0 +1,16 @@
+Qualcomm PM8xxx PMIC Vibrator
+
+PROPERTIES
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,pm8058-vib"
+ "qcom,pm8921-vib"
+
+EXAMPLE
+
+ vibrator {
+ compatible = "qcom,pm8058-vib";
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/9] Use regmap+devm+DT in pm8xxx input drivers
These patches move the pm8xxx input drivers over to use devm_* APIs and regmap. This breaks the dependency of these drivers on the pm8xxx specific read/write calls and also simplifies the probe code a bit. Finally we add devicetree support to these drivers so they can be probed on the platforms that are supported upstream. Changes since v3: * Dropped devm conversion patch for pwrkey * Fixed compilation of keypad Changes since v2: * Rebased to v3.14-rc3 Changes since v1: * Picked up Dmitry's version of devm for pwrkey * Added DT bindings and parsing patches * Dropped patches picked up by Dmitry Stephen Boyd (9): Input: pmic8xxx-keypad - Fix build by removing gpio configuration Input: pmic8xxx-keypad - Migrate to devm_* APIs Input: pmic8xxx-keypad - Migrate to regmap APIs Input: pmic8xxx-keypad - Migrate to DT Input: pmic8xxx-pwrkey - Migrate to DT Input: pm8xxx-vibrator - Add DT match table devicetree: bindings: Document PM8921/8058 keypads devicetree: bindings: Document PM8921/8058 power keys devicetree: bindings: Document PM8921/8058 vibrators .../bindings/input/qcom,pm8xxx-keypad.txt | 72 + .../bindings/input/qcom,pm8xxx-pwrkey.txt | 39 +++ .../devicetree/bindings/input/qcom,pm8xxx-vib.txt | 16 + drivers/input/keyboard/pmic8xxx-keypad.c | 348 - drivers/input/misc/pm8xxx-vibrator.c | 8 + drivers/input/misc/pmic8xxx-pwrkey.c | 33 +- include/linux/input/pmic8xxx-keypad.h | 52 --- include/linux/input/pmic8xxx-pwrkey.h | 31 -- 8 files changed, 286 insertions(+), 313 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt create mode 100644 Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt create mode 100644 Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt delete mode 100644 include/linux/input/pmic8xxx-keypad.h delete mode 100644 include/linux/input/pmic8xxx-pwrkey.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 7/9] devicetree: bindings: Document PM8921/8058 keypads
Document the keypad device found on PM8921 and PM8058 PMICs.
Cc:
Signed-off-by: Stephen Boyd
---
.../bindings/input/qcom,pm8xxx-keypad.txt | 72 ++
1 file changed, 72 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
new file mode 100644
index ..aa5a9c6cf512
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
@@ -0,0 +1,72 @@
+Qualcomm PM8xxx PMIC Keypad
+
+PROPERTIES
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,pm8058-keypad"
+ "qcom,pm8921-keypad"
+- interrupts:
+ Usage: required
+ Value type:
+ Definition: the first interrupt specifies the key sense interrupt
+ and the second interrupt specifies the key stuck interrupt.
+ The format of the specifier is defined by the binding
+ document describing the node's interrupt parent.
+
+- linux,keymap:
+ Usage: required
+ Value type:
+ Definition: the linux keymap. More information can be found in
+ input/matrix-keymap.txt.
+
+- keypad,num-rows:
+ Usage: required
+ Value type:
+ Definition: number of rows in the keymap. More information can be found
+ in input/matrix-keymap.txt.
+
+- keypad,num-columns:
+ Usage: required
+ Value type:
+ Definition: number of columns in the keymap. More information can be
+ found in input/matrix-keymap.txt.
+
+- debounce:
+ Usage: optional
+ Value type:
+ Definition: time in microseconds that key must be pressed or release
+ for key sense interrupt to trigger.
+
+- scan-delay:
+ Usage: optional
+ Value type:
+ Definition: time in microseconds to pause between successive scans
+ of the matrix array.
+
+- row-hold:
+ Usage: optional
+ Value type:
+ Definition: time in nanoseconds to pause between scans of each row in
+ the matrix array.
+
+EXAMPLE
+
+ keypad {
+ compatible = "qcom,pm8921-keypad";
+ interrupt-parent = <&pmicintc>;
+ interrupts = <74 1>, <75 1>;
+ linux,keymap = <
+ MATRIX_KEY(0, 0, KEY_VOLUMEUP)
+ MATRIX_KEY(0, 1, KEY_VOLUMEDOWN)
+ MATRIX_KEY(0, 2, KEY_CAMERA_FOCUS)
+ MATRIX_KEY(0, 3, KEY_CAMERA)
+ >;
+ keypad,num-rows = <1>;
+ keypad,num-columns = <5>;
+ debounce = <15>;
+ scan-delay = <32>;
+ row-hold = <91500>;
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Memory leak in scripts/dtc/util.c
On Thu, Feb 27, 2014 at 12:24 PM, wrote:
> From: Heinrich Schuchardt
>
> buf was leaked if out of memory
>
> Signed-off-by: Heinrich Schuchardt
> ---
> scripts/dtc/util.c |2 ++
> 1 file changed, 2 insertions(+)
This needs to be made against upstream dtc repo (on kernel.org now).
Also, there is a newly created list for dtc specific topics:
http://vger.kernel.org/vger-lists.html#devicetree-compiler
Rob
>
> diff --git a/scripts/dtc/util.c b/scripts/dtc/util.c
> index 2422c34..a1e2e59 100644
> --- a/scripts/dtc/util.c
> +++ b/scripts/dtc/util.c
> @@ -210,9 +210,11 @@ int utilfdt_read_err(const char *filename, char **buffp)
> do {
> /* Expand the buffer to hold the next chunk */
> if (offset == bufsize) {
> + char *buf_old = buf;
> bufsize *= 2;
> buf = realloc(buf, bufsize);
> if (!buf) {
> + buf = buf_old;
> ret = ENOMEM;
> break;
> }
> --
> 1.7.10.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/15] dt: binding: add binding for ImgTec IR block
On Thu, Feb 27, 2014 at 4:52 PM, James Hogan wrote:
> Hi Rob, Mark + DT maintainers,
>
> On Friday 07 February 2014 15:49:15 James Hogan wrote:
>> Add device tree binding for ImgTec Consumer Infrared block, specifically
>> major revision 1 of the hardware.
>>
>> Signed-off-by: James Hogan
>> Cc: Mauro Carvalho Chehab
>> Cc: linux-me...@vger.kernel.org
>> Cc: Rob Herring
>> Cc: Pawel Moll
>> Cc: Mark Rutland
>> Cc: Ian Campbell
>> Cc: Kumar Gala
>> Cc: devicetree@vger.kernel.org
>> Cc: Rob Landley
>> Cc: linux-...@vger.kernel.org
>> Cc: Tomasz Figa
>> ---
>> v3:
>> - Rename compatible string to "img,ir-rev1" (Rob Herring).
>> - Specify ordering of clocks explicitly (Rob Herring).
>
> I'd appreciate if somebody could give this another glance after the two
> changes listed above and Ack it (I'll probably be posting a v4 patchset
> tomorrow).
Looks fine.
Acked-by: Rob Herring
>>
>> v2:
>> - Future proof compatible string from "img,ir" to "img,ir1", where the 1
>> corresponds to the major revision number of the hardware (Tomasz
>> Figa).
>> - Added clock-names property and three specific clock names described in
>> the manual, only one of which is used by the current driver (Tomasz
>> Figa).
>> ---
>> .../devicetree/bindings/media/img-ir-rev1.txt | 34
>> ++ 1 file changed, 34 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/img-ir-rev1.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/img-ir-rev1.txt
>> b/Documentation/devicetree/bindings/media/img-ir-rev1.txt new file mode
>> 100644
>> index ..5434ce61b925
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/img-ir-rev1.txt
>> @@ -0,0 +1,34 @@
>> +* ImgTec Infrared (IR) decoder version 1
>> +
>> +This binding is for Imagination Technologies' Infrared decoder block,
>> +specifically major revision 1.
>> +
>> +Required properties:
>> +- compatible:Should be "img,ir-rev1"
>> +- reg: Physical base address of the controller and
>> length of
>> + memory mapped region.
>> +- interrupts:The interrupt specifier to the cpu.
>> +
>> +Optional properties:
>> +- clocks:List of clock specifiers as described in standard
>> + clock bindings.
>> + Up to 3 clocks may be specified in the following order:
>> + 1st:Core clock (defaults to 32.768KHz if omitted).
>> + 2nd:System side (fast) clock.
>> + 3rd:Power modulation clock.
>> +- clock-names: List of clock names corresponding to the clocks
>> + specified in the clocks property.
>> + Accepted clock names are:
>> + "core": Core clock.
>> + "sys": System clock.
>> + "mod": Power modulation clock.
>> +
>> +Example:
>> +
>> + ir@02006200 {
>> + compatible = "img,ir-rev1";
>> + reg = <0x02006200 0x100>;
>> + interrupts = <29 4>;
>> + clocks = <&clk_32khz>;
>> + clock-names = "core";
>> + };
--
To unsubscribe from this list: send the line "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] checkpatch: fix spurious vendor compatible warnings
On Thu, Feb 27, 2014 at 5:53 PM, Joe Perches wrote:
> On Thu, 2014-02-27 at 21:24 +0100, Florian Vaussard wrote:
>> On 02/27/2014 09:10 PM, Joe Perches wrote:
>> > On Thu, 2014-02-27 at 20:56 +0100, Florian Vaussard wrote:
>> >> With a compatible string like
>> >> compatible = "foo";
>> >> checkpatch will currently try to find "foo" in vendor-prefixes.txt,
>> >> which is wrong since the vendor prefix is empty in this specific case.
> []
>> > Some vendor names have dashes.
>> > I don't know if underscores are allowed.
>> >
>> > $ grep -rP --include=*.[ch] -oh "compatible\s*=\s*\"[^,]+,\w" * | \
>> > sed -r -e 's/\s//g' -e 's/,.$//' | sort | uniq -c | grep "[_-]"
>> > 1 compatible="active-semi
>> > 8 compatible="asahi-kasei
> []
>> In ePAPR v1.1, I could not find any strict requirement. It
>> is just saying:
>>
>> The recommended format is "manufacturer,model", where manufacturer is a
>> string describing the name of the manufacturer (such as a stock ticker
>> symbol), and model specifies the model number.
>
> Should there also be a check in .c and .h files for
> .compatible = "somestring"
Ideally, yes. I didn't do that because I figured there would be too
many variations in formatting compared to dts files.
> and
> OF_DEV_AUXDATA("somestring")
Probably not. OF_DEV_AUXDATA is hopefully temporary. There are 156
instances now and it looks like they've been going down since 3.8.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: of: Move the functions under CONFIG_OF_DMA instead of CONFIG_OF
On Thursday 27 February 2014 07:20 PM, Santosh Shilimkar wrote:
> The of-dma.c is compiled out with !CONFIG_OF_DMA but the functions in
> the header are kept under CONFIG_OF. Move them under CONFIG_OF_DMA
> to avoid build errors with CONFIG_OFF && !CONFIG_OF_DMA
>
> Cc: Grant Likely
> Cc: Rob Herring
> Signed-off-by: Santosh Shilimkar
> ---
> include/linux/of_dma.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
> index 0322363..3d2beab 100644
> --- a/include/linux/of_dma.h
> +++ b/include/linux/of_dma.h
> @@ -31,7 +31,7 @@ struct of_dma_filter_info {
> dma_filter_fn filter_fn;
> };
>
> -#ifdef CONFIG_OF
> +#ifdef CONFIG_OF_DMA
Sorry.. Typo here.. Should have been CONFIG_DMA_OF
>From 31242461b6ba5e8c0c5ee26e394fa4cab61e3aa1 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar
Date: Thu, 27 Feb 2014 19:13:36 -0500
Subject: [PATCH] dma: of: Move the functions under CONFIG_DMA_OF instead of
CONFIG_OF
The of-dma.c is compiled out with !CONFIG_DMA_OF but the functions in
the header are kept under CONFIG_OF. Move them under CONFIG_OF_DMA
to avoid build errors with CONFIG_OFF && !CONFIG_DMA_OF
Cc: Grant Likely
Cc: Rob Herring
Signed-off-by: Santosh Shilimkar
---
include/linux/of_dma.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index 0322363..0ea24f4 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -31,7 +31,7 @@ struct of_dma_filter_info {
dma_filter_fn filter_fn;
};
-#ifdef CONFIG_OF
+#ifdef CONFIG_DMA_OF
extern int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
--
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: [PATCHv2 14/16] ARM: OMAP3: hwmod data: cleanup data for IOMMUs
* Florian Vaussard [140227 01:19]: > Hi, > > On 02/26/2014 06:59 PM, Suman Anna wrote: > > Tony, > > > > On 02/26/2014 11:18 AM, Tony Lindgren wrote: > >> * Suman Anna [140213 10:19]: > >>> From: Florian Vaussard > >>> > >>> The irq numbers, ocp address space and device attribute data > >>> have all been cleaned up for OMAP3 IOMMUs. All this data is > >>> populated via the corresponding dt node. > >>> > >>> Signed-off-by: Florian Vaussard > >>> Signed-off-by: Suman Anna > >> > >> This will need to wait until we've made omap3 to be DT only > >> as this will break idling of things for the legacy booting. > >> > > > > OK, will drop this and I will adjust Patch 9 to support the legacy boot > > for OMAP3 ISP. > > > > BTW, Tony do you have a new window for omap3 to be DT onyl? I think a good point would be when we have DSS working with DT, and have a .dts file for the Pandora board. 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
[PATCH] dma: of: Move the functions under CONFIG_OF_DMA instead of CONFIG_OF
The of-dma.c is compiled out with !CONFIG_OF_DMA but the functions in
the header are kept under CONFIG_OF. Move them under CONFIG_OF_DMA
to avoid build errors with CONFIG_OFF && !CONFIG_OF_DMA
Cc: Grant Likely
Cc: Rob Herring
Signed-off-by: Santosh Shilimkar
---
include/linux/of_dma.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index 0322363..3d2beab 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -31,7 +31,7 @@ struct of_dma_filter_info {
dma_filter_fn filter_fn;
};
-#ifdef CONFIG_OF
+#ifdef CONFIG_OF_DMA
extern int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] pci: Add support for creating a generic host_bridge from device tree
On Thu, 2014-02-27 at 14:38 +0100, Arnd Bergmann wrote:
> On Thursday 27 February 2014 13:06:42 Liviu Dudau wrote:
> > Several platforms use a rather generic version of parsing
> > the device tree to find the host bridge ranges. Move the common code
> > into the generic PCI code and use it to create a pci_host_bridge
> > structure that can be used by arch code.
> >
> > Based on early attempts by Andrew Murray to unify the code.
> > Used powerpc and microblaze PCI code as starting point.
So that is only going to work for archs that don't have any special
twist. For example it won't work for powerpc which is why Andrew
original approach didn't fly.
The range walk helpers do help though, I need to review in more details
and test Andrew powerpc patch here and will merge it.
> > Signed-off-by: Liviu Dudau
>
> Please add Benjamin Herrenschmidt to Cc here, I think it would be helpful
> to get his input so we can make this work on powerpc as well.
Tricky... We would need hooks which would turn the whole thing into a
pile of spaghetti. I think we should stick to using the range helpers
(Andrew latest patch), which makes the powerpc code a lot smaller,
and leave it at that.
> > diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
> > index 06ace62..feb8436 100644
> > --- a/drivers/pci/host-bridge.c
> > +++ b/drivers/pci/host-bridge.c
> > @@ -6,9 +6,13 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> >
> > #include "pci.h"
> >
> > +static int domain_nr;
> > +
>
> For correctness, I think you want an 'atomic_t' here and use
> atomic_inc_return() to get a new value.
>
> > static struct pci_bus *find_pci_root_bus(struct pci_bus *bus)
> > {
> > while (bus->parent)
> > @@ -91,3 +95,133 @@ void pcibios_bus_to_resource(struct pci_bus *bus,
> > struct resource *res,
> > res->end = region->end + offset;
> > }
> > EXPORT_SYMBOL(pcibios_bus_to_resource);
> > +
> > +/**
> > + * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
> > + * @dev: device node of the host bridge having the range property
> > + * @resources: list where the range of resources will be added after DT
> > parsing
> > + * @io_base: pointer to a variable that will contain the physical address
> > for
> > + * the start of the I/O range.
> > + *
> > + * If this function returns an error then the @resources list will be
> > freed.
> > + *
> > + * This function will parse the "ranges" property of a PCI host bridge
> > device
> > + * node and setup the resource mapping based on its content. It is expected
> > + * that the property conforms with the Power ePAPR document.
> > + *
> > + * Each architecture is then offered the chance of applying their own
> > + * filtering of pci_host_bridge_windows based on their own restrictions by
> > + * calling pcibios_fixup_bridge_ranges(). The filtered list of windows
> > + * can then be used when creating a pci_host_bridge structure.
> > + */
> > +static int pci_host_bridge_of_get_ranges(struct device_node *dev,
> > + struct list_head *resources, resource_size_t *io_base)
> > +{
> > + struct resource *res;
> > + struct of_pci_range range;
> > + struct of_pci_range_parser parser;
> > + int err;
> > +
> > + pr_info("PCI host bridge %s ranges:\n", dev->full_name);
> > +
> > + /* Check for ranges property */
> > + err = of_pci_range_parser_init(&parser, dev);
> > + if (err)
> > + return err;
> > +
> > + pr_debug("Parsing ranges property...\n");
> > + for_each_of_pci_range(&parser, &range) {
> > + /* Read next ranges element */
> > + pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> > + range.pci_space, range.pci_addr);
> > + pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> > + range.cpu_addr, range.size);
> > +
> > + /*
> > +* If we failed translation or got a zero-sized region
> > +* then skip this range
> > +*/
> > + if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> > + continue;
Shouldn't that test move into the parsing helper ?
> > + res = kzalloc(sizeof(struct resource), GFP_KERNEL);
> > + if (!res) {
> > + err = -ENOMEM;
> > + goto bridge_ranges_nomem;
> > + }
> > +
> > + of_pci_range_to_resource(&range, dev, res);
> > +
> > + if (resource_type(res) == IORESOURCE_IO)
> > + *io_base = range.cpu_addr;
You don't care about the size of the IO space ?
> > + pci_add_resource_offset(resources, res,
> > + res->start - range.pci_addr);
> > + }
>
> This is not the correct resource for I/O space at all. Please talk
> to Will, I've been over this with him in detail and he probably
> understands it now. I assume you are both working in the same
> building.
Yes, the IO offsets work differ
Re: [PATCH] checkpatch: fix spurious vendor compatible warnings
On Thu, 2014-02-27 at 21:24 +0100, Florian Vaussard wrote:
> On 02/27/2014 09:10 PM, Joe Perches wrote:
> > On Thu, 2014-02-27 at 20:56 +0100, Florian Vaussard wrote:
> >> With a compatible string like
> >> compatible = "foo";
> >> checkpatch will currently try to find "foo" in vendor-prefixes.txt,
> >> which is wrong since the vendor prefix is empty in this specific case.
[]
> > Some vendor names have dashes.
> > I don't know if underscores are allowed.
> >
> > $ grep -rP --include=*.[ch] -oh "compatible\s*=\s*\"[^,]+,\w" * | \
> > sed -r -e 's/\s//g' -e 's/,.$//' | sort | uniq -c | grep "[_-]"
> > 1 compatible="active-semi
> > 8 compatible="asahi-kasei
[]
> In ePAPR v1.1, I could not find any strict requirement. It
> is just saying:
>
> The recommended format is “manufacturer,model”, where manufacturer is a
> string describing the name of the manufacturer (such as a stock ticker
> symbol), and model specifies the model number.
Should there also be a check in .c and .h files for
.compatible = "somestring"
and
OF_DEV_AUXDATA("somestring")
?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] phy-rcar-usb-gen2: add device tree support
Hello.
On 02/27/2014 07:03 PM, Ben Dooks wrote:
Signed-off-by: Ben Dooks
Reviewed-by: Ian Molton
---
Cc: linux-...@vger.kernel.org (open list:USB PHY LAYER)
Cc: linux...@vger.kernel.org (open list:ARM/SHMOBILE ARM...)
Cc: Magnus Damm (supporter:ARM/SHMOBILE ARM...)
Cc: Simon Horman (supporter:ARM/SHMOBILE ARM...)
Cc: devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND...)
---
drivers/usb/phy/phy-rcar-gen2-usb.c | 35
++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/phy/phy-rcar-gen2-usb.c
b/drivers/usb/phy/phy-rcar-gen2-usb.c
index db3ab34..906b74b 100644
--- a/drivers/usb/phy/phy-rcar-gen2-usb.c
+++ b/drivers/usb/phy/phy-rcar-gen2-usb.c
[...]
@@ -203,16 +212,31 @@ static int rcar_gen2_usb_phy_probe(struct
platform_device *pdev)
[...]
+if (of_id) {
[...]
+int len = 0;
+
+if (of_get_property(dev->of_node, "renesas,usb0-hs", &len))
+priv->ugctrl2 = USBHS_UGCTRL2_USB0_HS;
+else
+priv->ugctrl2 = USBHS_UGCTRL2_USB0_PCI;
+
+if (of_get_property(dev->of_node, "renesas,usb2-ss", &len))
+priv->ugctrl2 |= USBHS_UGCTRL2_USB2_SS;
Where is the bindings file you document these properties in?
Should have been in another patch in the series.
I didn't see it.
I thought it went out, I will need to go check.
It turned out that I'd already replied to that email that I had seen all 6
patches but not the binding patch, so most probably it didn't went out that
time. I've seen the latter patch (just not posted to linux-usb), so no problem
here.
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 3/6] spi: sh-msiof: Add support for R-Car H2 and M2
Hi Geert, On Thursday 27 February 2014 12:09:52 Geert Uytterhoeven wrote: > On Thu, Feb 27, 2014 at 11:41 AM, Laurent Pinchart wrote: > >> >> -- compatible : "renesas,sh-msiof" for SuperH, or > >> >> +- compatible : "renesas,msiof-" for SoCs, > >> >> + "renesas,sh-msiof" for SuperH, or > >> >>"renesas,sh-mobile-msiof" for SH Mobile series. > >> >> + Examples with soctypes are: > >> >> + "renesas,msiof-sh7724" (SH) > >> > > >> > Given that the driver doesn't handle the "renesas,msiof-sh7724" > >> > compatible string this might not be a good example. Furthermore SuperH > >> > doesn't have DT support. I would thus drop the "renesas,sh-msiof" > >> > compatible string from patch 1/6 and wouldn't mention sh7724 here. I > >> > very much doubt that someone would have developed DT support for SuperH > >> > on the side and shipped products that would be broken by this change > >> > :-) > >> > >> Upon reading your comment again: do you suggest to also remove the plain > >> "renesas,sh-msiof"? That one was present before, since DT support was > >> added to the driver in > >> > >> commit cf9c86efecf9510e62388fd174cf607671c59fa3 > >> Author: Bastian Hecht > >> Date: Wed Dec 12 12:54:48 2012 +0100 > >> > >> spi/sh-msiof: Add device tree parsing to driver > >> > >> This adds the capability to retrieve setup data from the device tree > >> node. The usage of platform data is still available. > >> > >> Signed-off-by: Bastian Hecht > >> Signed-off-by: Grant Likely > >> > >> So I prefer not to remove any pre-existing compatible values. > >> Do you agree? > > > > I'd like to remove it (in a separate patch) if we can. The reason is that > > keeping the DT ABI both forward- and backward-compatible is pretty painful > > enough without having to care about compatibility strings that have no > > user. I'd rather work on adding DT support for SuperH MSIOF later when > > we'll have a platform we can test it on, instead of trying to guess now > > what the needs will be, get users later and realize even later on that we > > made a mistake that we can't fix because those users will have DT > > binaries in the wild. Every unneeded bit of DT bindings that we keep in > > the kernel is one potential problem for future binary compatibility. > > I agree about the complexity of keeping the DT ABI forward- and > backward-compatible. > > However, in this case I don't think it hurts that much to just keep it: > - DT compatible values and platform device names are kept in sync > through a pointer to the same struct sh_msiof_chipdata, so there's > not much maintenance needed. > - DT compatible "renesas,sh-msiof" means exactly the same as > the "spi_sh_msiof" platform device name, which is currently in use. > > So even if SuperH never moves to DT, we have to keep support for that > specific MSIOF implementation, unless we drop the platform device version, > too (Hmm, maybe that's what you're alluding to ;-) Of course, I'm not trying to get support for SuperH dropped, I'm sure someone would realize and complain before the end of the century ;-) > And if we remove "renesas,sh-msiof", we should probably remove > "renesas,sh-mobile-msiof", too, as there are no current users, and it also > assumes the same MSIOF implementation? I'm not too familiar with the MSIOF hardware, can "renesas,sh-mobile-msiof" be used as a fallback for the currently support ARM SoCs ? > Bastian: What was your real plan with "renesas,sh-msiof" and > "renesas,sh-mobile-msiof"? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/15] dt: binding: add binding for ImgTec IR block
Hi Rob, Mark + DT maintainers,
On Friday 07 February 2014 15:49:15 James Hogan wrote:
> Add device tree binding for ImgTec Consumer Infrared block, specifically
> major revision 1 of the hardware.
>
> Signed-off-by: James Hogan
> Cc: Mauro Carvalho Chehab
> Cc: linux-me...@vger.kernel.org
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: devicetree@vger.kernel.org
> Cc: Rob Landley
> Cc: linux-...@vger.kernel.org
> Cc: Tomasz Figa
> ---
> v3:
> - Rename compatible string to "img,ir-rev1" (Rob Herring).
> - Specify ordering of clocks explicitly (Rob Herring).
I'd appreciate if somebody could give this another glance after the two
changes listed above and Ack it (I'll probably be posting a v4 patchset
tomorrow).
Thanks
James
>
> v2:
> - Future proof compatible string from "img,ir" to "img,ir1", where the 1
> corresponds to the major revision number of the hardware (Tomasz
> Figa).
> - Added clock-names property and three specific clock names described in
> the manual, only one of which is used by the current driver (Tomasz
> Figa).
> ---
> .../devicetree/bindings/media/img-ir-rev1.txt | 34
> ++ 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/img-ir-rev1.txt
>
> diff --git a/Documentation/devicetree/bindings/media/img-ir-rev1.txt
> b/Documentation/devicetree/bindings/media/img-ir-rev1.txt new file mode
> 100644
> index ..5434ce61b925
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/img-ir-rev1.txt
> @@ -0,0 +1,34 @@
> +* ImgTec Infrared (IR) decoder version 1
> +
> +This binding is for Imagination Technologies' Infrared decoder block,
> +specifically major revision 1.
> +
> +Required properties:
> +- compatible:Should be "img,ir-rev1"
> +- reg: Physical base address of the controller and
> length of
> + memory mapped region.
> +- interrupts:The interrupt specifier to the cpu.
> +
> +Optional properties:
> +- clocks:List of clock specifiers as described in standard
> + clock bindings.
> + Up to 3 clocks may be specified in the following order:
> + 1st:Core clock (defaults to 32.768KHz if omitted).
> + 2nd:System side (fast) clock.
> + 3rd:Power modulation clock.
> +- clock-names: List of clock names corresponding to the clocks
> + specified in the clocks property.
> + Accepted clock names are:
> + "core": Core clock.
> + "sys": System clock.
> + "mod": Power modulation clock.
> +
> +Example:
> +
> + ir@02006200 {
> + compatible = "img,ir-rev1";
> + reg = <0x02006200 0x100>;
> + interrupts = <29 4>;
> + clocks = <&clk_32khz>;
> + clock-names = "core";
> + };
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] spi: sh-msiof: Remove "renesas,msiof-sh7724" from bindings
Hi Geert, Thank you for the patch. On Thursday 27 February 2014 13:47:17 Geert Uytterhoeven wrote: > From: Geert Uytterhoeven > > It's not implemented in the driver, so it's a bad example. > > Signed-off-by: Geert Uytterhoeven Acked-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/spi/sh-msiof.txt |1 - > 1 file changed, 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt > b/Documentation/devicetree/bindings/spi/sh-msiof.txt index > 1f0cb33763a1..f24baf3b6cc1 100644 > --- a/Documentation/devicetree/bindings/spi/sh-msiof.txt > +++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt > @@ -5,7 +5,6 @@ Required properties: >"renesas,sh-msiof" for SuperH, or >"renesas,sh-mobile-msiof" for SH Mobile series. >Examples with soctypes are: > - "renesas,msiof-sh7724" (SH) >"renesas,msiof-r8a7790" (R-Car H2) >"renesas,msiof-r8a7791" (R-Car M2) > - reg : Offset and length of the register set for the > device -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "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/4] ARM: mvebu: move DT Dove to MVEBU
With all the DT support preparation done, we are able to move Dove
to MVEBU easily. Legacy non-DT mach-dove is left untouched to rot
for a while before removal. Also, convert SATA PHY Kconfig entry,
which is DT-only.
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
v1->v2:
- just rename CONFIG_ARCH_DOVE to CONFIG_MACH_DOVE in dts/Makefile
(Suggested by Jason Cooper)
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Kishon Vijay Abraham I
Cc: devicetree@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/boot/dts/Makefile | 2 +-
arch/arm/mach-dove/Kconfig | 12
arch/arm/mach-dove/Makefile | 1 -
arch/arm/mach-mvebu/Kconfig | 12
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} | 20
drivers/phy/Kconfig | 2 +-
7 files changed, 23 insertions(+), 27 deletions(-)
rename arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} (61%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 032030361bef..21317af7fe48 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -55,7 +55,7 @@ dtb-$(CONFIG_ARCH_BERLIN) += \
berlin2cd-google-chromecast.dtb
dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
da850-evm.dtb
-dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
+dtb-$(CONFIG_MACH_DOVE) += dove-cm-a510.dtb \
dove-cubox.dtb \
dove-d2plug.dtb \
dove-d3plug.dtb \
diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
index 0bc7cdf8cf46..d8c439c89ea9 100644
--- a/arch/arm/mach-dove/Kconfig
+++ b/arch/arm/mach-dove/Kconfig
@@ -20,18 +20,6 @@ config MACH_CM_A510
Say 'Y' here if you want your kernel to support the
CompuLab CM-A510 Board.
-config MACH_DOVE_DT
- bool "Marvell Dove Flattened Device Tree"
- select DOVE_CLK
- select ORION_IRQCHIP
- select ORION_TIMER
- select REGULATOR
- select REGULATOR_FIXED_VOLTAGE
- select USE_OF
- help
- Say 'Y' here if you want your kernel to support the
- Marvell Dove using flattened device tree.
-
endmenu
endif
diff --git a/arch/arm/mach-dove/Makefile b/arch/arm/mach-dove/Makefile
index cbc5c0618788..b608a21919fb 100644
--- a/arch/arm/mach-dove/Makefile
+++ b/arch/arm/mach-dove/Makefile
@@ -2,5 +2,4 @@ obj-y += common.o
obj-$(CONFIG_DOVE_LEGACY) += irq.o mpp.o
obj-$(CONFIG_PCI) += pcie.o
obj-$(CONFIG_MACH_DOVE_DB) += dove-db-setup.o
-obj-$(CONFIG_MACH_DOVE_DT) += board-dt.o
obj-$(CONFIG_MACH_CM_A510) += cm-a510.o
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 5e269d7263ce..966e5c6b9944 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -46,6 +46,18 @@ config MACH_ARMADA_XP
Say 'Y' here if you want your kernel to support boards based
on the Marvell Armada XP SoC with device tree.
+config MACH_DOVE
+ bool "Marvell Dove boards" if ARCH_MULTI_V7
+ select CACHE_L2X0
+ select CPU_PJ4
+ select DOVE_CLK
+ select ORION_IRQCHIP
+ select ORION_TIMER
+ select PINCTRL_DOVE
+ help
+ Say 'Y' here if you want your kernel to support the
+ Marvell Dove using flattened device tree.
+
endmenu
endif
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 878aebe98dcc..dd3e7188f75d 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -5,6 +5,7 @@ AFLAGS_coherency_ll.o := -Wa,-march=armv7-a
obj-y += system-controller.o mvebu-soc-id.o
obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o
+obj-$(CONFIG_MACH_DOVE) += dove.o
obj-$(CONFIG_ARCH_MVEBU)+= coherency.o coherency_ll.o pmsu.o
obj-$(CONFIG_SMP)+= platsmp.o headsmp.o
obj-$(CONFIG_HOTPLUG_CPU)+= hotplug.o
diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-mvebu/dove.c
similarity index 61%
rename from arch/arm/mach-dove/board-dt.c
rename to arch/arm/mach-mvebu/dove.c
index 49fa9abd09da..5e5a43624237 100644
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach-mvebu/dove.c
@@ -1,5 +1,5 @@
/*
- * arch/arm/mach-dove/board-dt.c
+ * arch/arm/mach-mvebu/dove.c
*
* Marvell Dove 88AP510 System On Chip FDT Board
*
@@ -9,17 +9,14 @@
*/
#include
-#include
+#include
#include
#include
#include
#include
-#include
-#include
-#include
#include "common.h"
-static void __init dove_dt_init(void)
+static void __init dove_init(void)
{
pr_info("Dove 88AP510 SoC\n");
@@ -30,14 +27,13 @@ static void
Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework
HI,
>> >> >> This patch adds function set_speed to the generic PHY framework
>> >> >> operation
>> >> >> structure. This function can be called to instruct the PHY underlying
>> >> >> layer
>> >> >> at specified lane to configure for specified speed in hertz.
>> >> >
>> >> > why ? looks like clk_set_rate() is your friend here. Can you be more
>> >> > descriptive of the use case ? When will this be used ?
>> >> >
>> >>
>> >> The phy_set_speed is used to configure the operation speed of the PHY
>> >> at run-time. The clock interface in general is used to configure the
>> >> clock input to the IP. I don't believe they are the same thing. Maybe
>> >> it will be clear in my response to your second email
>> >
>> > The problem with this is that you end up adding SATA-specific details to
>> > something which is supposed to be generic.
>>
>> Setting the operation speed is pretty generic from an interface point
>> of view. An generic multi-purpose PHY can support multiple speed. If
>
> no it's not. Specially when you consider that your "speed" argument can
> be just about anything and depending on the underlying bus, it *will* be
> treated differently. Note that e.g. in OMAP devices the exact *same* PHY
> IP is used for PCIe, SATA and USB... now, let's assume for the sake of
> argument that we were to implement ->set_speed() in that environment,
> how do you plan to do that ? a 6MHz arguments isn't valid from USB stand
> point and could mean different things in PCIe or SATA.
>
Correct me if I am wrong here. If the same PHY is used for PCIe, SATA,
and USB, would you not need to indicate what speed the PHY should be
operated at - unless the underlying IP magically negotiate and
configured automatically? If so, what about PHY isn't so intelligent?
How should you suggest that we handle these?
>> the upper layer wish to operate at an specified speed (say for testing
>> purpose and etc), it can be allowed.
>
> anything for testing purposes, should be limited to test scenarios.
Testing purpose is only one use case. Another use case is to limit the
speed so that I can confirm the driver actually works with various
speed of the device and handle correctly.
>
>> > After negoatiation, don't you
>> > get any interrupt from your PHY indicating that link speed negotiation
>> > is done ? Or is that IRQ only on AHCI IP ?
>>
>> There is NO interrupt from the PHY. The IRQ is assoicated with the
>> AHCI IP. With SATA host flow, it starts off with an COMRESET to start
>> the link negotiation. At that point, it will poll for completion.
>>
>> Any other concerns?
>
> hey, calm down... just trying to prevent us from applying something
> which isn't truly generic and I don't think "->set_speed" is generic
> enough. The semantics of the "speed" argument won't be valid for all use
> cases.
>
> I can already see people using that to pass
> USB_SPEED_{LOW,FULL,HIGH,SUPER}, instead of actual speed numbers. We wil
> end up with a mess to handle from a PHY driver, specially in cases such
> as OMAP where, as mentioned above, the same IP is used for SATA, PCIe
> and USB3.
>
This PHY isn't as "intelligent" as other PHY's. What would you suggest
as I need an method to indicate to the underlying PHY that I want to
operate at an specified speed?
-Loc
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: bcm21664: Add board support.
Add support for the Broadcom BCM21664 mobile SoC. It has two Cortex-A9
cores like the BCM281xx family of chips. BCM21664 and BCM281xx share
many IP blocks in addition to the ARM cores.
Signed-off-by: Markus Mayer
---
arch/arm/mach-bcm/Makefile |6 ++-
arch/arm/mach-bcm/board_bcm21664.c | 78
2 files changed, 82 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-bcm/board_bcm21664.c
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index c2ccd5a..0e2e52e 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -1,5 +1,5 @@
#
-# Copyright (C) 2012-2013 Broadcom Corporation
+# Copyright (C) 2012-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
@@ -10,6 +10,8 @@
# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
-obj-$(CONFIG_ARCH_BCM_MOBILE) := board_bcm281xx.o bcm_kona_smc.o
bcm_kona_smc_asm.o kona.o
+obj-$(CONFIG_ARCH_BCM_MOBILE) := board_bcm281xx.o board_bcm21664.o \
+ bcm_kona_smc.o bcm_kona_smc_asm.o kona.o
+
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_bcm_kona_smc_asm.o :=-Wa,-march=armv7-a$(plus_sec)
diff --git a/arch/arm/mach-bcm/board_bcm21664.c
b/arch/arm/mach-bcm/board_bcm21664.c
new file mode 100644
index 000..d3ef7e5
--- /dev/null
+++ b/arch/arm/mach-bcm/board_bcm21664.c
@@ -0,0 +1,78 @@
+/*
+ * 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 "bcm_kona_smc.h"
+#include "kona.h"
+
+#define RSTMGR_DT_STRING "brcm,bcm21664-resetmgr"
+
+#define RSTMGR_REG_WR_ACCESS_OFFSET0
+#define RSTMGR_REG_CHIP_SOFT_RST_OFFSET4
+
+#define RSTMGR_WR_PASSWORD 0xa5a5
+#define RSTMGR_WR_PASSWORD_SHIFT 8
+#define RSTMGR_WR_ACCESS_ENABLE1
+
+static void bcm21644_restart(enum reboot_mode mode, const char *cmd)
+{
+ void __iomem *base;
+ struct device_node *resetmgr;
+
+ resetmgr = of_find_compatible_node(NULL, NULL, RSTMGR_DT_STRING);
+ if (!resetmgr) {
+ pr_emerg("Couldn't find " RSTMGR_DT_STRING "\n");
+ return;
+ }
+ base = of_iomap(resetmgr, 0);
+ if (!base) {
+ pr_emerg("Couldn't map " RSTMGR_DT_STRING "\n");
+ return;
+ }
+
+ /*
+* A soft reset is triggered by writing a 0 to bit 0 of the soft reset
+* register. To write to that register we must first write the password
+* and the enable bit in the write access enable register.
+*/
+ writel((RSTMGR_WR_PASSWORD << RSTMGR_WR_PASSWORD_SHIFT) |
+ RSTMGR_WR_ACCESS_ENABLE,
+ base + RSTMGR_REG_WR_ACCESS_OFFSET);
+ writel(0, base + RSTMGR_REG_CHIP_SOFT_RST_OFFSET);
+
+ /* Wait for reset */
+ while (1);
+}
+
+static void __init bcm21644_init(void)
+{
+ of_platform_populate(NULL, of_default_bus_match_table, NULL,
+ &platform_bus);
+ kona_l2_cache_init();
+}
+
+static const char * const bcm21664_dt_compat[] = {
+ "brcm,bcm21664",
+ NULL,
+};
+
+DT_MACHINE_START(BCM21664_DT, "BCM21664 Broadcom Application Processor")
+ .init_machine = bcm21644_init,
+ .restart = bcm21644_restart,
+ .dt_compat = bcm21664_dt_compat,
+MACHINE_END
--
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 1/3] ARM: DT: bcm21664: Device tree bindings
Add binding documents for the Broadcom BCM21664 SoC.
Signed-off-by: Markus Mayer
---
.../devicetree/bindings/arm/bcm/bcm21664.txt | 15 +++
.../devicetree/bindings/arm/bcm/kona-resetmgr.txt | 14 ++
2 files changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/bcm/bcm21664.txt
create mode 100644 Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt
diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt
b/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt
new file mode 100644
index 000..e077425
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt
@@ -0,0 +1,15 @@
+Broadcom BCM21664 device tree bindings
+--
+
+This document describes the device tree bindings for boards with the BCM21664
+SoC.
+
+Required root node property:
+ - compatible: brcm,bcm21664
+
+Example:
+ / {
+ model = "BCM21664 SoC";
+ compatible = "brcm,bcm21664";
+ [...]
+ }
diff --git a/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt
b/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt
new file mode 100644
index 000..93f31ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt
@@ -0,0 +1,14 @@
+Broadcom Kona Family Reset Manager
+--
+
+The reset manager is used on the Broadcom BCM21664 SoC.
+
+Required properties:
+ - compatible: brcm,bcm21664-resetmgr
+ - reg: memory address & range
+
+Example:
+ brcm,resetmgr@35001f00 {
+ compatible = "brcm,bcm21664-resetmgr";
+ reg = <0x35001f00 0x24>;
+ };
--
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 3/3] ARM: dts: bcm21664: Add device tree files.
Add device tree files for the Broadcom BCM21664 SoC.
Signed-off-by: Markus Mayer
---
arch/arm/boot/dts/Makefile|3 +-
arch/arm/boot/dts/bcm21664-garnet.dts | 56 +++
arch/arm/boot/dts/bcm21664.dtsi | 292 +
3 files changed, 350 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/bcm21664-garnet.dts
create mode 100644 arch/arm/boot/dts/bcm21664.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0320303..0c1853a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,7 +48,8 @@ dtb-$(CONFIG_ARCH_AT91) += sama5d36ek.dtb
dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm11351-brt.dtb \
- bcm28155-ap.dtb
+ bcm28155-ap.dtb \
+ bcm21664-garnet.dtb
dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
dtb-$(CONFIG_ARCH_BERLIN) += \
berlin2-sony-nsz-gs7.dtb\
diff --git a/arch/arm/boot/dts/bcm21664-garnet.dts
b/arch/arm/boot/dts/bcm21664-garnet.dts
new file mode 100644
index 000..e87cb26
--- /dev/null
+++ b/arch/arm/boot/dts/bcm21664-garnet.dts
@@ -0,0 +1,56 @@
+/*
+ * 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.
+ */
+
+/dts-v1/;
+
+#include
+
+#include "bcm21664.dtsi"
+
+/ {
+ model = "BCM21664 Garnet board";
+ compatible = "brcm,bcm21664-garnet", "brcm,bcm21664";
+
+ memory {
+ reg = <0x8000 0x4000>; /* 1 GB */
+ };
+
+ uart@3e00 {
+ status = "okay";
+ };
+
+ sdio1: sdio@3f18 {
+ max-frequency = <4800>;
+ status = "okay";
+ };
+
+ sdio2: sdio@3f19 {
+ non-removable;
+ max-frequency = <4800>;
+ status = "okay";
+ };
+
+ sdio4: sdio@3f1b {
+ max-frequency = <4800>;
+ cd-gpios = <&gpio 91 GPIO_ACTIVE_LOW>;
+ status = "okay";
+ };
+
+ usbotg: usb@3f12 {
+ status = "okay";
+ };
+
+ usbphy: usb-phy@3f13 {
+ status = "okay";
+ };
+};
diff --git a/arch/arm/boot/dts/bcm21664.dtsi b/arch/arm/boot/dts/bcm21664.dtsi
new file mode 100644
index 000..08a44d4
--- /dev/null
+++ b/arch/arm/boot/dts/bcm21664.dtsi
@@ -0,0 +1,292 @@
+/*
+ * 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 "skeleton.dtsi"
+
+/ {
+ model = "BCM21664 SoC";
+ compatible = "brcm,bcm21664";
+ interrupt-parent = <&gic>;
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ gic: interrupt-controller@3ff00100 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x3ff01000 0x1000>,
+ <0x3ff00100 0x100>;
+ };
+
+ smc@0x3404e000 {
+ compatible = "brcm,bcm21664-smc", "brcm,kona-smc";
+ reg = <0x3404e000 0x400>; /* 1 KiB in SRAM */
+ };
+
+ uart@3e00 {
+ compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
+ status = "disabled";
+ reg = <0x3e00 0x118>;
+ clocks = <&uartb_clk>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ };
+
+ uart@3e001000 {
+ compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
+ status = "disabled";
+ reg = <0x3e001000 0x118>;
+ clocks = <&uartb2_clk>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ };
+
+ uart@3e002000 {
+ compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
+ status = "disabled";
+ reg = <0x3e002000 0x118>;
+ clocks = <&uartb3_clk>;
+ inte
[PATCH 0/3] ARM: bcm21664: Add initial support.
This series adds initial support for the Broadcom BCM21664 mobile SoC. The series depends on the series "ARM: bcm281xx: Consolidate code": https://lkml.org/lkml/2014/2/25/548 Markus Mayer (3): ARM: DT: bcm21664: Device tree bindings ARM: bcm21664: Add board support. ARM: dts: bcm21664: Add device tree files. .../devicetree/bindings/arm/bcm/bcm21664.txt | 15 + .../devicetree/bindings/arm/bcm/kona-resetmgr.txt | 14 + arch/arm/boot/dts/Makefile |3 +- arch/arm/boot/dts/bcm21664-garnet.dts | 56 arch/arm/boot/dts/bcm21664.dtsi| 292 arch/arm/mach-bcm/Makefile |6 +- arch/arm/mach-bcm/board_bcm21664.c | 78 ++ 7 files changed, 461 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/bcm/bcm21664.txt create mode 100644 Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt create mode 100644 arch/arm/boot/dts/bcm21664-garnet.dts create mode 100644 arch/arm/boot/dts/bcm21664.dtsi create mode 100644 arch/arm/mach-bcm/board_bcm21664.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: [PATCH 3/4] ARM: mvebu: move DT Dove to MVEBU
On Thu, Feb 27, 2014 at 10:43:59PM +0100, Sebastian Hesselbarth wrote:
> On 02/27/2014 10:40 PM, Jason Cooper wrote:
> >On Thu, Feb 27, 2014 at 10:28:04PM +0100, Sebastian Hesselbarth wrote:
> >>With all the DT support preparation done, we are able to move Dove
> >>to MVEBU easily. Legacy non-DT mach-dove is left untouched to rot
> >>for a while before removal. Also, convert SATA PHY Kconfig entry,
> >>which is DT-only.
> >>
> >>Signed-off-by: Sebastian Hesselbarth
> >>---
> >>Cc: Rob Herring
> >>Cc: Pawel Moll
> >>Cc: Mark Rutland
> >>Cc: Ian Campbell
> >>Cc: Kumar Gala
> >>Cc: Russell King
> >>Cc: Jason Cooper
> >>Cc: Andrew Lunn
> >>Cc: Gregory Clement
> >>Cc: Kishon Vijay Abraham I
> >>Cc: devicetree@vger.kernel.org
> >>Cc: linux-arm-ker...@lists.infradead.org
> >>Cc: linux-ker...@vger.kernel.org
> >>---
> >> arch/arm/boot/dts/Makefile | 12 ++--
> >> arch/arm/mach-dove/Kconfig | 12
> >> arch/arm/mach-dove/Makefile | 1 -
> >> arch/arm/mach-mvebu/Kconfig | 12
> >> arch/arm/mach-mvebu/Makefile | 1 +
> >> arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} | 20
> >>
> >> drivers/phy/Kconfig | 2 +-
> >> 7 files changed, 28 insertions(+), 32 deletions(-)
> >> rename arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} (61%)
> >>
> >>diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >>index 032030361bef..376a2573e500 100644
> >>--- a/arch/arm/boot/dts/Makefile
> >>+++ b/arch/arm/boot/dts/Makefile
> >>@@ -55,11 +55,6 @@ dtb-$(CONFIG_ARCH_BERLIN) += \
> >>berlin2cd-google-chromecast.dtb
> >> dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
> >>da850-evm.dtb
> >>-dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
> >>- dove-cubox.dtb \
> >>- dove-d2plug.dtb \
> >>- dove-d3plug.dtb \
> >>- dove-dove-db.dtb
> >> dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
> >> dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
> >>exynos4210-smdkv310.dtb \
> >>@@ -132,7 +127,12 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> >>armada-xp-gp.dtb \
> >>armada-xp-netgear-rn2120.dtb \
> >>armada-xp-matrix.dtb \
> >>- armada-xp-openblocks-ax3-4.dtb
> >>+ armada-xp-openblocks-ax3-4.dtb \
> >>+ dove-cm-a510.dtb \
> >>+ dove-cubox.dtb \
> >>+ dove-d2plug.dtb \
> >>+ dove-d3plug.dtb \
> >>+ dove-dove-db.dtb
> >
> >This is going to conflict badly with
> >
> > a02dd0271d01 ARM: mvebu: select dtbs from MACH_ARMADA_*
> >
> >Perhaps you could mimic what Andrew did in his series:
> >
> >dove := dove-cm-a510.dtb \
> > dove-cubox.dtb \
> > dove-d2plug.dtb \
> > dove-d3plug.dtb \
> > dove-dove-db.dtb
> >dtb-$(CONFIG_ARCH_DOVE) += $(dove)
> >dtb-$(CONFIG_MACH_DOVE) += $(dove)
>
> Ok, will do - except dtb-$(CONFIG_ARCH_DOVE) above.. there is no
> DT in ARCH_DOVE after this patch.
Ok, then there's no need for 'dove :=', just s/ARCH_DOVE/MACH_DOVE/ on
the original without movement.
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 3/4] ARM: mvebu: move DT Dove to MVEBU
On 02/27/2014 10:40 PM, Jason Cooper wrote:
On Thu, Feb 27, 2014 at 10:28:04PM +0100, Sebastian Hesselbarth wrote:
With all the DT support preparation done, we are able to move Dove
to MVEBU easily. Legacy non-DT mach-dove is left untouched to rot
for a while before removal. Also, convert SATA PHY Kconfig entry,
which is DT-only.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Kishon Vijay Abraham I
Cc: devicetree@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/boot/dts/Makefile | 12 ++--
arch/arm/mach-dove/Kconfig | 12
arch/arm/mach-dove/Makefile | 1 -
arch/arm/mach-mvebu/Kconfig | 12
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} | 20
drivers/phy/Kconfig | 2 +-
7 files changed, 28 insertions(+), 32 deletions(-)
rename arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} (61%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 032030361bef..376a2573e500 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -55,11 +55,6 @@ dtb-$(CONFIG_ARCH_BERLIN) += \
berlin2cd-google-chromecast.dtb
dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
da850-evm.dtb
-dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
- dove-cubox.dtb \
- dove-d2plug.dtb \
- dove-d3plug.dtb \
- dove-dove-db.dtb
dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
@@ -132,7 +127,12 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
armada-xp-gp.dtb \
armada-xp-netgear-rn2120.dtb \
armada-xp-matrix.dtb \
- armada-xp-openblocks-ax3-4.dtb
+ armada-xp-openblocks-ax3-4.dtb \
+ dove-cm-a510.dtb \
+ dove-cubox.dtb \
+ dove-d2plug.dtb \
+ dove-d3plug.dtb \
+ dove-dove-db.dtb
This is going to conflict badly with
a02dd0271d01 ARM: mvebu: select dtbs from MACH_ARMADA_*
Perhaps you could mimic what Andrew did in his series:
dove := dove-cm-a510.dtb \
dove-cubox.dtb \
dove-d2plug.dtb \
dove-d3plug.dtb \
dove-dove-db.dtb
dtb-$(CONFIG_ARCH_DOVE) += $(dove)
dtb-$(CONFIG_MACH_DOVE) += $(dove)
Ok, will do - except dtb-$(CONFIG_ARCH_DOVE) above.. there is no
DT in ARCH_DOVE after this patch.
We plan on re-alphabetizing next window to prevent bad conflicts in this
window.
Good!
Sebastian
--
To unsubscribe from this list: send the line "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] ARM: mvebu: move DT Dove to MVEBU
On Thu, Feb 27, 2014 at 10:28:04PM +0100, Sebastian Hesselbarth wrote:
> With all the DT support preparation done, we are able to move Dove
> to MVEBU easily. Legacy non-DT mach-dove is left untouched to rot
> for a while before removal. Also, convert SATA PHY Kconfig entry,
> which is DT-only.
>
> Signed-off-by: Sebastian Hesselbarth
> ---
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: Russell King
> Cc: Jason Cooper
> Cc: Andrew Lunn
> Cc: Gregory Clement
> Cc: Kishon Vijay Abraham I
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> ---
> arch/arm/boot/dts/Makefile | 12 ++--
> arch/arm/mach-dove/Kconfig | 12
> arch/arm/mach-dove/Makefile | 1 -
> arch/arm/mach-mvebu/Kconfig | 12
> arch/arm/mach-mvebu/Makefile | 1 +
> arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} | 20
>
> drivers/phy/Kconfig | 2 +-
> 7 files changed, 28 insertions(+), 32 deletions(-)
> rename arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} (61%)
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 032030361bef..376a2573e500 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -55,11 +55,6 @@ dtb-$(CONFIG_ARCH_BERLIN) += \
> berlin2cd-google-chromecast.dtb
> dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
> da850-evm.dtb
> -dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
> - dove-cubox.dtb \
> - dove-d2plug.dtb \
> - dove-d3plug.dtb \
> - dove-dove-db.dtb
> dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
> dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
> exynos4210-smdkv310.dtb \
> @@ -132,7 +127,12 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> armada-xp-gp.dtb \
> armada-xp-netgear-rn2120.dtb \
> armada-xp-matrix.dtb \
> - armada-xp-openblocks-ax3-4.dtb
> + armada-xp-openblocks-ax3-4.dtb \
> + dove-cm-a510.dtb \
> + dove-cubox.dtb \
> + dove-d2plug.dtb \
> + dove-d3plug.dtb \
> + dove-dove-db.dtb
This is going to conflict badly with
a02dd0271d01 ARM: mvebu: select dtbs from MACH_ARMADA_*
Perhaps you could mimic what Andrew did in his series:
dove := dove-cm-a510.dtb \
dove-cubox.dtb \
dove-d2plug.dtb \
dove-d3plug.dtb \
dove-dove-db.dtb
dtb-$(CONFIG_ARCH_DOVE) += $(dove)
dtb-$(CONFIG_MACH_DOVE) += $(dove)
We plan on re-alphabetizing next window to prevent bad conflicts in this
window.
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 v12 1/4] PHY: Add function set_speed to generic PHY framework
Hi,
On Thu, Feb 27, 2014 at 01:09:57PM -0800, Loc Ho wrote:
> >> >> This patch adds function set_speed to the generic PHY framework
> >> >> operation
> >> >> structure. This function can be called to instruct the PHY underlying
> >> >> layer
> >> >> at specified lane to configure for specified speed in hertz.
> >> >
> >> > why ? looks like clk_set_rate() is your friend here. Can you be more
> >> > descriptive of the use case ? When will this be used ?
> >> >
> >>
> >> The phy_set_speed is used to configure the operation speed of the PHY
> >> at run-time. The clock interface in general is used to configure the
> >> clock input to the IP. I don't believe they are the same thing. Maybe
> >> it will be clear in my response to your second email
> >
> > The problem with this is that you end up adding SATA-specific details to
> > something which is supposed to be generic.
>
> Setting the operation speed is pretty generic from an interface point
> of view. An generic multi-purpose PHY can support multiple speed. If
no it's not. Specially when you consider that your "speed" argument can
be just about anything and depending on the underlying bus, it *will* be
treated differently. Note that e.g. in OMAP devices the exact *same* PHY
IP is used for PCIe, SATA and USB... now, let's assume for the sake of
argument that we were to implement ->set_speed() in that environment,
how do you plan to do that ? a 6MHz arguments isn't valid from USB stand
point and could mean different things in PCIe or SATA.
> the upper layer wish to operate at an specified speed (say for testing
> purpose and etc), it can be allowed.
anything for testing purposes, should be limited to test scenarios.
> > After negoatiation, don't you
> > get any interrupt from your PHY indicating that link speed negotiation
> > is done ? Or is that IRQ only on AHCI IP ?
>
> There is NO interrupt from the PHY. The IRQ is assoicated with the
> AHCI IP. With SATA host flow, it starts off with an COMRESET to start
> the link negotiation. At that point, it will poll for completion.
>
> Any other concerns?
hey, calm down... just trying to prevent us from applying something
which isn't truly generic and I don't think "->set_speed" is generic
enough. The semantics of the "speed" argument won't be valid for all use
cases.
I can already see people using that to pass
USB_SPEED_{LOW,FULL,HIGH,SUPER}, instead of actual speed numbers. We wil
end up with a mess to handle from a PHY driver, specially in cases such
as OMAP where, as mentioned above, the same IP is used for SATA, PCIe
and USB3.
--
balbi
signature.asc
Description: Digital signature
[PATCH 1/4] ARM: dove: add system controller node
This adds a DT node for the system-controller found on Marvell Dove
SoCs.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: devicetree@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/boot/dts/dove.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 187fd46b7b5e..bd63452b18c0 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -186,6 +186,11 @@
reg = <0x2 0x80>, <0x800100 0x8>;
};
+ sysc: system-ctrl@2 {
+ compatible = "marvell,orion-system-controller";
+ reg = <0x2 0x110>;
+ };
+
bridge_intc: bridge-interrupt-ctrl@20110 {
compatible = "marvell,orion-bridge-intc";
interrupt-controller;
--
1.8.5.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: [PATCHv1 1/2] rx51_battery: convert to iio consumer
Hi Sebastian, On Wed, Feb 26, 2014 at 10:54 PM, Sebastian Reichel wrote: > Hi, > > On Wed, Feb 26, 2014 at 10:43:40PM +0100, Belisko Marek wrote: >> [...] >> > + int val, err; >> > + err = iio_read_channel_average_raw(channel, &val); >> Where this function comes from? I cannot find it in current linux-next >> (only iio_read_channel_raw()). Am I missing some patches? Thx. > > Ah right. I planned to send a patch adding this function together > with the rx51-battery patchset, but it seems I forgot to include it. > > Sorry for the inconvenience. I will send it out as a separate patch > now. > >> BTW when I convert to iio consumer and use DT some of values work >> but some of them just report 0 :( (I don't have latest twl4030-madc >> iio patches). > > Can you retry with the twl4030-madc iio patch from today? The > older patchsets, which do not contain the "tested on real hw" > note are slightly broken. Well I've tried and it's worse :). I got during booting: [2.218383] ERROR: could not get IIO channel /battery:temp(0) [2.224639] platform battery.4: Driver twl4030_madc_battery requests probe deferral Not sure if it's just error or warning but temp is always reported as 0 (and also other values in sysfs). My patches ca be found here: https://patchwork.kernel.org/patch/3735981/ https://patchwork.kernel.org/patch/3735961/ https://patchwork.kernel.org/patch/3735941/ > > -- Sebastian BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.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 V2 1/3] dt: palmas: support IRQ inversion at the board level
On 02/27/2014 02:02 PM, Graeme Gregory wrote: > On Thu, Feb 27, 2014 at 01:51:19PM -0700, Stephen Warren wrote: >> Some boards or SoCs have an inverter between the PMIC IRQ output pin and >> the IRQ controller input signal. >> >> The IRQ specifier in DT is meant to represent the IRQ flags at the input >> to the IRQ controller. >> >> The Palmas HW's IRQ output has configurable polarity. Software needs to >> know which polarity to choose for the IRQ output. Software may be tempted >> to extract the IRQ polarity from the IRQ specifier in order to make this >> choice. >> >> That approach works fine if the IRQ signal is routed directly from the >> PMIC to the IRQ controller with no intervening logic. However, if the >> signal is inverted between the two, this approach gets the wrong answer. >> >> Add an additional optional DT property which indicates that such an >> inversion occurs. This allows DT to give complete information about the >> desired IRQ output polarity to software. >> >> An alternative would have been to add a new non-optional DT parameter to >> indicate the exact desired output polarity. However, this would have been >> an incompatible change to the DT binding. >> diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt >> b/Documentation/devicetree/bindings/mfd/palmas.txt >> +- ti,irq-externally-inverted : If missing, the polarity of the Palmas IRQ >> + output should be set to the opposite of the polarity indicated by the IRQ >> + specifier in the interrupts property. If absent, the polarity should be >> + configured to match. This allows the representation of an inverter between >> + the Palmas IRQ output and the interrupt parent's IRQ input. > > This has got to be the wrong way to do things, all this leads to is every > device doing this property in its own way and having totally inconsistent > properties all meaning the same thing. > > If there is some other hardware inverting lines then there should be > a generic binding for this in DT. This is not describing the palmas hardware > but some external object to the palmas. I'd be fine with removing the "ti," vendor prefix from the property name, and promoting it to be a cross-device standard. I'm not sure that many devices will need this though; most don't have configurable output polarity. Still, I guess that shouldn't stop us from creating standards for the cases where it is needed. If the DT reviewers can ack the concept, I'm happy to respin the patch with the more generic property name. -- To unsubscribe from this list: send the line "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] Convert twl4030_madc_battery to IIO and add DT aupport
This patches are based on Sebastian Reichel work [1] which convert twl4030_madc mfd to iio framework. Patches was tested on gta04 board. twl4030_madc_battery driver is converted in first patch to iio consumer and in next patches is added support for devicetree. [1] - https://lkml.org/lkml/2014/2/26/482 Marek Belisko (3): power: twl4030-madc-battery: Convert to iio consumer. power: twl4030_madc_battery: Add device tree support. Documentation: DT: Document twl4030-madc-battery bindings. .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++ drivers/power/twl4030_madc_battery.c | 155 - 2 files changed, 165 insertions(+), 33 deletions(-) create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt -- 1.8.3.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 1/3] power: twl4030-madc-battery: Convert to iio consumer.
Signed-off-by: Marek Belisko
---
drivers/power/twl4030_madc_battery.c | 74
1 file changed, 41 insertions(+), 33 deletions(-)
diff --git a/drivers/power/twl4030_madc_battery.c
b/drivers/power/twl4030_madc_battery.c
index 7ef445a..42685df 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -19,10 +19,14 @@
#include
#include
#include
+#include
struct twl4030_madc_battery {
struct power_supply psy;
struct twl4030_madc_bat_platform_data *pdata;
+ struct iio_channel *channel_temp;
+ struct iio_channel *channel_ichg;
+ struct iio_channel *channel_vbat;
};
static enum power_supply_property twl4030_madc_bat_props[] = {
@@ -38,43 +42,35 @@ static enum power_supply_property twl4030_madc_bat_props[]
= {
POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
};
-static int madc_read(int index)
+static int madc_read(struct iio_channel *channel)
{
- struct twl4030_madc_request req;
- int val;
-
- req.channels = index;
- req.method = TWL4030_MADC_SW2;
- req.type = TWL4030_MADC_WAIT;
- req.do_avg = 0;
- req.raw = false;
- req.func_cb = NULL;
-
- val = twl4030_madc_conversion(&req);
- if (val < 0)
- return val;
-
- return req.rbuf[ffs(index) - 1];
+ int val, err;
+ err = iio_read_channel_raw(channel, &val);
+ if (err < 0) {
+ pr_info("Error:%d\n", err);
+ return err;
+ }
+ return val;
}
-static int twl4030_madc_bat_get_charging_status(void)
+static int twl4030_madc_bat_get_charging_status(struct twl4030_madc_battery
*bt)
{
- return (madc_read(TWL4030_MADC_ICHG) > 0) ? 1 : 0;
+ return (madc_read(bt->channel_ichg) > 0) ? 1 : 0;
}
-static int twl4030_madc_bat_get_voltage(void)
+static int twl4030_madc_bat_get_voltage(struct twl4030_madc_battery *bt)
{
- return madc_read(TWL4030_MADC_VBAT);
+ return madc_read(bt->channel_vbat);
}
-static int twl4030_madc_bat_get_current(void)
+static int twl4030_madc_bat_get_current(struct twl4030_madc_battery *bt)
{
- return madc_read(TWL4030_MADC_ICHG) * 1000;
+ return madc_read(bt->channel_ichg) * 1000;
}
-static int twl4030_madc_bat_get_temp(void)
+static int twl4030_madc_bat_get_temp(struct twl4030_madc_battery *bt)
{
- return madc_read(TWL4030_MADC_BTEMP) * 10;
+ return madc_read(bt->channel_temp) * 10;
}
static int twl4030_madc_bat_voltscale(struct twl4030_madc_battery *bat,
@@ -84,7 +80,7 @@ static int twl4030_madc_bat_voltscale(struct
twl4030_madc_battery *bat,
int i, res = 0;
/* choose charging curve */
- if (twl4030_madc_bat_get_charging_status())
+ if (twl4030_madc_bat_get_charging_status(bat))
calibration = bat->pdata->charging;
else
calibration = bat->pdata->discharging;
@@ -119,23 +115,23 @@ static int twl4030_madc_bat_get_property(struct
power_supply *psy,
switch (psp) {
case POWER_SUPPLY_PROP_STATUS:
if (twl4030_madc_bat_voltscale(bat,
- twl4030_madc_bat_get_voltage()) > 95)
+ twl4030_madc_bat_get_voltage(bat)) > 95)
val->intval = POWER_SUPPLY_STATUS_FULL;
else {
- if (twl4030_madc_bat_get_charging_status())
+ if (twl4030_madc_bat_get_charging_status(bat))
val->intval = POWER_SUPPLY_STATUS_CHARGING;
else
val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
}
break;
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
- val->intval = twl4030_madc_bat_get_voltage() * 1000;
+ val->intval = twl4030_madc_bat_get_voltage(bat) * 1000;
break;
case POWER_SUPPLY_PROP_TECHNOLOGY:
val->intval = POWER_SUPPLY_TECHNOLOGY_LION;
break;
case POWER_SUPPLY_PROP_CURRENT_NOW:
- val->intval = twl4030_madc_bat_get_current();
+ val->intval = twl4030_madc_bat_get_current(bat);
break;
case POWER_SUPPLY_PROP_PRESENT:
/* assume battery is always present */
@@ -143,23 +139,23 @@ static int twl4030_madc_bat_get_property(struct
power_supply *psy,
break;
case POWER_SUPPLY_PROP_CHARGE_NOW: {
int percent = twl4030_madc_bat_voltscale(bat,
- twl4030_madc_bat_get_voltage());
+ twl4030_madc_bat_get_voltage(bat));
val->intval = (percent * bat->pdata->capacity) / 100;
break;
}
case POWER_SUPPLY_PROP_CAPACITY:
val->intval = twl4030_madc_bat_voltscale(bat,
-
[PATCH 3/3] Documentation: DT: Document twl4030-madc-battery bindings.
Signed-off-by: Marek Belisko
---
.../bindings/power_supply/twl4030_madc_battery.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
diff --git
a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
new file mode 100644
index 000..fd0b6d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
@@ -0,0 +1,43 @@
+twl4030_madc_battery
+
+Required properties:
+ - compatible : "ti,twl4030-madc-battery"
+ - capacity : battery capacity in uAh
+ - charging-calibration-data : list of voltage(mV):level(%) values
+ for charging calibration (see example)
+ - discharging-calibration-data : list of voltage(mV):level(%) values
+ for discharging calibration (see example)
+ - io-channels: Should contain IIO channel specifiers
+ for each element in io-channel-names.
+- io-channel-names: Should contain the following values:
+ * "temp" - The ADC channel for temperature reading
+ * "ichg" - The ADC channel for battery charging status
+ * "vbat" - The ADC channel to measure the battery voltage
+
+Example:
+ madc-battery {
+ compatible = "ti,twl4030-madc-battery";
+ capacity = <120>;
+ charging-calibration-data = <4200 100
+4100 75
+4000 55
+3900 25
+3800 5
+3700 2
+3600 1
+3300 0>;
+
+ discharging-calibration-data = <4200 100
+ 4100 95
+ 4000 70
+ 3800 50
+ 3700 10
+ 3600 5
+ 3300 0>;
+ io-channels = <&twl_madc 1>,
+ <&twl_madc 10>,
+ <&twl_madc 12>;
+ io-channel-names = "temp",
+ "ichg",
+ "vbat";
+ };
--
1.8.3.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] power: twl4030_madc_battery: Add device tree support.
Signed-off-by: Marek Belisko
---
drivers/power/twl4030_madc_battery.c | 83 +++-
1 file changed, 82 insertions(+), 1 deletion(-)
diff --git a/drivers/power/twl4030_madc_battery.c
b/drivers/power/twl4030_madc_battery.c
index 42685df..24c69f7 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
struct twl4030_madc_battery {
struct power_supply psy;
@@ -184,6 +185,82 @@ static int twl4030_cmp(const void *a, const void *b)
((struct twl4030_madc_bat_calibration *)a)->voltage;
}
+#ifdef CONFIG_OF
+static struct twl4030_madc_bat_platform_data *
+ twl4030_madc_dt_probe(struct platform_device *pdev)
+{
+ struct twl4030_madc_bat_platform_data *pdata;
+ struct device_node *np = pdev->dev.of_node;
+ int ret;
+ int i, proplen;
+
+ pdata = devm_kzalloc(&pdev->dev,
+ sizeof(struct twl4030_madc_bat_platform_data),
+ GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ ret = of_property_read_u32(np, "capacity", &pdata->capacity);
+ if (ret != 0)
+ return ERR_PTR(-EINVAL);
+
+ /* parse and prepare charging data */
+ proplen = of_property_count_u32_elems(np, "charging-calibration-data");
+ if (proplen < 0) {
+ dev_warn(&pdev->dev, "No 'charging-calibration-data' property
found\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ pdata->charging = devm_kzalloc(&pdev->dev,
+ sizeof(struct twl4030_madc_bat_calibration) * (proplen / 2),
+ GFP_KERNEL);
+
+ for (i = 0; i < proplen / 2; i++) {
+ of_property_read_u32_index(np, "charging-calibration-data",
+ i * 2,
+ (u32 *)&pdata->charging[i].voltage);
+ of_property_read_u32_index(np, "charging-calibration-data",
+ i * 2 + 1,
+ (u32 *)&pdata->charging[i].level);
+ }
+
+ /* parse and prepare discharging data */
+ proplen = of_property_count_u32_elems(np,
+ "discharging-calibration-data");
+ if (proplen < 0) {
+ dev_warn(&pdev->dev, "No 'discharging-calibration-data'
property found\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ pdata->discharging = devm_kzalloc(&pdev->dev,
+ sizeof(struct twl4030_madc_bat_calibration) * (proplen / 2),
+ GFP_KERNEL);
+
+ for (i = 0; i < proplen / 2; i++) {
+ of_property_read_u32_index(np, "discharging-calibration-data",
+ i * 2,
+ (u32
*)&pdata->discharging[i].voltage);
+ of_property_read_u32_index(np, "discharging-calibration-data",
+ i * 2 + 1,
+ (u32 *)&pdata->discharging[i].level);
+ }
+
+ return pdata;
+}
+
+static const struct of_device_id of_twl4030_madc_match[] = {
+ { .compatible = "ti,twl4030-madc-battery", },
+ {},
+};
+
+#else
+static struct twl4030_madc_bat_platform_data *
+ twl4030_madc_dt_probe(struct platform_device *pdev)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
static int twl4030_madc_battery_probe(struct platform_device *pdev)
{
struct twl4030_madc_battery *twl4030_madc_bat;
@@ -193,6 +270,9 @@ static int twl4030_madc_battery_probe(struct
platform_device *pdev)
if (!twl4030_madc_bat)
return -ENOMEM;
+ if (!pdata)
+ pdata = twl4030_madc_dt_probe(pdev);
+
twl4030_madc_bat->psy.name = "twl4030_battery";
twl4030_madc_bat->psy.type = POWER_SUPPLY_TYPE_BATTERY;
twl4030_madc_bat->psy.properties = twl4030_madc_bat_props;
@@ -201,7 +281,7 @@ static int twl4030_madc_battery_probe(struct
platform_device *pdev)
twl4030_madc_bat->psy.get_property = twl4030_madc_bat_get_property;
twl4030_madc_bat->psy.external_power_changed =
twl4030_madc_bat_ext_changed;
-
+
twl4030_madc_bat->channel_temp = iio_channel_get(&pdev->dev, "temp");
if (IS_ERR(twl4030_madc_bat->channel_temp))
return PTR_ERR(twl4030_madc_bat->channel_temp);
@@ -242,6 +322,7 @@ static int twl4030_madc_battery_remove(struct
platform_device *pdev)
static struct platform_driver twl4030_madc_battery_driver = {
.driver = {
.name = "twl4030_madc_battery",
+ .of_match_table = of_match_ptr(of_twl4030_madc_match),
},
.probe = twl4030_madc_battery_probe,
.remove = twl4030_madc_battery_remove,
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscri
[PATCH 3/4] ARM: mvebu: move DT Dove to MVEBU
With all the DT support preparation done, we are able to move Dove
to MVEBU easily. Legacy non-DT mach-dove is left untouched to rot
for a while before removal. Also, convert SATA PHY Kconfig entry,
which is DT-only.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Kishon Vijay Abraham I
Cc: devicetree@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/boot/dts/Makefile | 12 ++--
arch/arm/mach-dove/Kconfig | 12
arch/arm/mach-dove/Makefile | 1 -
arch/arm/mach-mvebu/Kconfig | 12
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} | 20
drivers/phy/Kconfig | 2 +-
7 files changed, 28 insertions(+), 32 deletions(-)
rename arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} (61%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 032030361bef..376a2573e500 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -55,11 +55,6 @@ dtb-$(CONFIG_ARCH_BERLIN) += \
berlin2cd-google-chromecast.dtb
dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
da850-evm.dtb
-dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
- dove-cubox.dtb \
- dove-d2plug.dtb \
- dove-d3plug.dtb \
- dove-dove-db.dtb
dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
@@ -132,7 +127,12 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
armada-xp-gp.dtb \
armada-xp-netgear-rn2120.dtb \
armada-xp-matrix.dtb \
- armada-xp-openblocks-ax3-4.dtb
+ armada-xp-openblocks-ax3-4.dtb \
+ dove-cm-a510.dtb \
+ dove-cubox.dtb \
+ dove-d2plug.dtb \
+ dove-d3plug.dtb \
+ dove-dove-db.dtb
dtb-$(CONFIG_ARCH_MXC) += \
imx25-karo-tx25.dtb \
imx25-pdk.dtb \
diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
index 0bc7cdf8cf46..d8c439c89ea9 100644
--- a/arch/arm/mach-dove/Kconfig
+++ b/arch/arm/mach-dove/Kconfig
@@ -20,18 +20,6 @@ config MACH_CM_A510
Say 'Y' here if you want your kernel to support the
CompuLab CM-A510 Board.
-config MACH_DOVE_DT
- bool "Marvell Dove Flattened Device Tree"
- select DOVE_CLK
- select ORION_IRQCHIP
- select ORION_TIMER
- select REGULATOR
- select REGULATOR_FIXED_VOLTAGE
- select USE_OF
- help
- Say 'Y' here if you want your kernel to support the
- Marvell Dove using flattened device tree.
-
endmenu
endif
diff --git a/arch/arm/mach-dove/Makefile b/arch/arm/mach-dove/Makefile
index cbc5c0618788..b608a21919fb 100644
--- a/arch/arm/mach-dove/Makefile
+++ b/arch/arm/mach-dove/Makefile
@@ -2,5 +2,4 @@ obj-y += common.o
obj-$(CONFIG_DOVE_LEGACY) += irq.o mpp.o
obj-$(CONFIG_PCI) += pcie.o
obj-$(CONFIG_MACH_DOVE_DB) += dove-db-setup.o
-obj-$(CONFIG_MACH_DOVE_DT) += board-dt.o
obj-$(CONFIG_MACH_CM_A510) += cm-a510.o
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 5e269d7263ce..966e5c6b9944 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -46,6 +46,18 @@ config MACH_ARMADA_XP
Say 'Y' here if you want your kernel to support boards based
on the Marvell Armada XP SoC with device tree.
+config MACH_DOVE
+ bool "Marvell Dove boards" if ARCH_MULTI_V7
+ select CACHE_L2X0
+ select CPU_PJ4
+ select DOVE_CLK
+ select ORION_IRQCHIP
+ select ORION_TIMER
+ select PINCTRL_DOVE
+ help
+ Say 'Y' here if you want your kernel to support the
+ Marvell Dove using flattened device tree.
+
endmenu
endif
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 878aebe98dcc..dd3e7188f75d 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -5,6 +5,7 @@ AFLAGS_coherency_ll.o := -Wa,-march=armv7-a
obj-y += system-controller.o mvebu-soc-id.o
obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o
+obj-$(CONFIG_MACH_DOVE) += dove.o
obj-$(CONFIG_ARCH_MVEBU)+= coherency.o coherency_ll.o pmsu.o
obj-$(CONFIG_SMP)+= platsmp.o headsmp.o
obj-$(CONFIG_HOTPLUG_CPU)+= hotplug.o
diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-mvebu/dove.c
similarity index 61%
rename from arch/arm/mach-dove/board-dt.c
rename to arch/arm/mach-mvebu/dove.c
index 49fa9abd09da..5e5a43624237 100644
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach
Re: [PATCH V2 1/3] dt: palmas: support IRQ inversion at the board level
On Thu, Feb 27, 2014 at 01:51:19PM -0700, Stephen Warren wrote: > From: Stephen Warren > > Some boards or SoCs have an inverter between the PMIC IRQ output pin and > the IRQ controller input signal. > > The IRQ specifier in DT is meant to represent the IRQ flags at the input > to the IRQ controller. > > The Palmas HW's IRQ output has configurable polarity. Software needs to > know which polarity to choose for the IRQ output. Software may be tempted > to extract the IRQ polarity from the IRQ specifier in order to make this > choice. > > That approach works fine if the IRQ signal is routed directly from the > PMIC to the IRQ controller with no intervening logic. However, if the > signal is inverted between the two, this approach gets the wrong answer. > > Add an additional optional DT property which indicates that such an > inversion occurs. This allows DT to give complete information about the > desired IRQ output polarity to software. > > An alternative would have been to add a new non-optional DT parameter to > indicate the exact desired output polarity. However, this would have been > an incompatible change to the DT binding. > > Signed-off-by: Stephen Warren > Acked-by: Laxman Dewangan > Acked-by: Lee Jones > --- > v2: Split V1's patch 1/2 into separate patches 1/3 and 2/3. > --- > Documentation/devicetree/bindings/mfd/palmas.txt | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt > b/Documentation/devicetree/bindings/mfd/palmas.txt > index e5f0f8303461..76ec509d5f87 100644 > --- a/Documentation/devicetree/bindings/mfd/palmas.txt > +++ b/Documentation/devicetree/bindings/mfd/palmas.txt > @@ -18,6 +18,12 @@ Required properties: >ti,tps659038 > and also the generic series names >ti,palmas > +- interrupts : Should contain a single entry for the IRQ output. > +- ti,irq-externally-inverted : If missing, the polarity of the Palmas IRQ > + output should be set to the opposite of the polarity indicated by the IRQ > + specifier in the interrupts property. If absent, the polarity should be > + configured to match. This allows the representation of an inverter between > + the Palmas IRQ output and the interrupt parent's IRQ input. This has got to be the wrong way to do things, all this leads to is every device doing this property in its own way and having totally inconsistent properties all meaning the same thing. If there is some other hardware inverting lines then there should be a generic binding for this in DT. This is not describing the palmas hardware but some external object to the palmas. Graeme > - interrupt-controller : palmas has its own internal IRQs > - #interrupt-cells : should be set to 2 for IRQ number and flags >The first cell is the IRQ number. > -- > 1.8.1.5 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] ARM: dts: keystone: Use dma-ranges property
From: Grygorii Strashko
The dma-ranges property has to be specified per bus and has format:
< DMA addr > - Base DMA address for Bus (Bus format 32-bits)
< CPU addr > - Corresponding base CPU address (CPU format 64-bits)
< DMA range size > - Size of supported DMA range
Cc: Russell King
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Grant Likely
Cc: Rob Herring
Signed-off-by: Grygorii Strashko
Signed-off-by: Santosh Shilimkar
---
arch/arm/boot/dts/keystone.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index b420290..171579d 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -96,6 +96,7 @@
compatible = "ti,keystone","simple-bus";
interrupt-parent = <&gic>;
ranges = <0x0 0x0 0x0 0xc000>;
+ dma-ranges = <0x8000 0x8 0x 0x8000>;
rstctrl: reset-controller {
compatible = "ti,keystone-reset";
--
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 v2 2/7] ARM: mm: Remove unsed dma_to_virt()
From: Grygorii Strashko
Remove dma_to_virt() as there are no in-tree users of it.
Cc: Russell King
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Greg Ungerer
Cc: Tony Lindgren
Signed-off-by: Grygorii Strashko
Signed-off-by: Santosh Shilimkar
---
arch/arm/include/asm/dma-mapping.h | 14 +-
arch/arm/mach-iop13xx/include/mach/memory.h | 11 ---
arch/arm/mach-ks8695/include/mach/memory.h |2 --
arch/arm/mach-omap1/include/mach/memory.h |4
4 files changed, 1 insertion(+), 30 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index 247ed72..e365158 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -51,7 +51,7 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
#endif
/*
- * dma_to_pfn/pfn_to_dma/dma_to_virt/virt_to_dma are architecture private
+ * dma_to_pfn/pfn_to_dma/virt_to_dma are architecture private
* functions used internally by the DMA-mapping API to provide DMA
* addresses. They must not be used by drivers.
*/
@@ -70,13 +70,6 @@ static inline unsigned long dma_to_pfn(struct device *dev,
dma_addr_t addr)
return __bus_to_pfn(addr) + dev->archdata.dma_pfn_offset;
}
-static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
-{
- if (!dev)
- return NULL;
- return (void *)__bus_to_virt(__pfn_to_bus(dma_to_pfn(dev, addr)));
-}
-
static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
{
if (!dev)
@@ -96,11 +89,6 @@ static inline unsigned long dma_to_pfn(struct device *dev,
dma_addr_t addr)
return __arch_dma_to_pfn(dev, addr);
}
-static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
-{
- return __arch_dma_to_virt(dev, addr);
-}
-
static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
{
return __arch_virt_to_dma(dev, addr);
diff --git a/arch/arm/mach-iop13xx/include/mach/memory.h
b/arch/arm/mach-iop13xx/include/mach/memory.h
index 7c032d0..1223c85 100644
--- a/arch/arm/mach-iop13xx/include/mach/memory.h
+++ b/arch/arm/mach-iop13xx/include/mach/memory.h
@@ -36,17 +36,6 @@ static inline void __iomem *__lbus_to_virt(dma_addr_t x)
#define is_lbus_device(dev)\
(dev && strncmp(dev->bus->name, "platform", 8) == 0)
-#define __arch_dma_to_virt(dev, addr) \
- ({ \
- void * __virt; \
- dma_addr_t __dma = addr;\
- if (is_lbus_device(dev) && __is_lbus_dma(__dma))\
- __virt = __lbus_to_virt(__dma); \
- else\
- __virt = (void *)__phys_to_virt(__dma); \
- __virt; \
- })
-
#define __arch_virt_to_dma(dev, addr) \
({ \
void * __virt = addr; \
diff --git a/arch/arm/mach-ks8695/include/mach/memory.h
b/arch/arm/mach-ks8695/include/mach/memory.h
index 95e731a..f42477c 100644
--- a/arch/arm/mach-ks8695/include/mach/memory.h
+++ b/arch/arm/mach-ks8695/include/mach/memory.h
@@ -31,8 +31,6 @@
/* Platform-bus mapping */
extern struct bus_type platform_bus_type;
#define is_lbus_device(dev)(dev && dev->bus == &platform_bus_type)
-#define __arch_dma_to_virt(dev, x) ({ (void *) (is_lbus_device(dev) ? \
- __phys_to_virt(x) : __bus_to_virt(x));
})
#define __arch_virt_to_dma(dev, x) ({ is_lbus_device(dev) ? \
(dma_addr_t)__virt_to_phys((unsigned
long)x) \
: (dma_addr_t)__virt_to_bus(x); })
diff --git a/arch/arm/mach-omap1/include/mach/memory.h
b/arch/arm/mach-omap1/include/mach/memory.h
index 3c25305..73f86db 100644
--- a/arch/arm/mach-omap1/include/mach/memory.h
+++ b/arch/arm/mach-omap1/include/mach/memory.h
@@ -43,10 +43,6 @@
__phys_to_pfn(__dma);\
})
-#define __arch_dma_to_virt(dev, addr) ({ (void *) (is_lbus_device(dev) ? \
- lbus_to_virt(addr) : \
- __phys_to_virt(addr)); })
-
#define __arch_virt_to_dma(dev, addr) ({ unsigned long __addr = (unsigned
long)(addr); \
(dma_addr_t) (is_lbus_device(dev) ? \
virt_to_lbus(__addr) : \
--
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
M
[PATCH v2 3/7] dma: of: introduce of_dma_get_range() helper
From: Grygorii Strashko
The of_dma_get_range() allows to find "dma-range" property for
the specified device and parse it.
dma-ranges format:
DMA addr (dma_addr) : naddr cells
CPU addr (phys_addr_t) : pna cells
size : nsize cells
Cc: Russell King
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Grant Likely
Cc: Rob Herring
Signed-off-by: Grygorii Strashko
Signed-off-by: Santosh Shilimkar
---
drivers/dma/of-dma.c | 86
include/linux/of_dma.h |8 +
2 files changed, 94 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index e8fe9dc..9b51768 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
static LIST_HEAD(of_dma_list);
static DEFINE_MUTEX(of_dma_lock);
@@ -218,3 +219,88 @@ struct dma_chan *of_dma_simple_xlate(struct
of_phandle_args *dma_spec,
&dma_spec->args[0]);
}
EXPORT_SYMBOL_GPL(of_dma_simple_xlate);
+
+/**
+ * of_dma_get_range - Get DMA range info
+ * @np:device node to get DMA range info
+ * @dma_addr: pointer to store initial DMA address of DMA range
+ * @paddr: pointer to store initial CPU address of DMA range
+ * @size: pointer to store size of DMA range
+ *
+ * Look in bottom up direction for the first "dma-range" property
+ * and parse it.
+ * dma-ranges format:
+ * DMA addr (dma_addr) : naddr cells
+ * CPU addr (phys_addr_t) : pna cells
+ * size: nsize cells
+ *
+ * It returns -ENODEV if "dma-ranges" property was not found
+ * for this device in DT.
+ */
+extern int of_dma_get_range(struct device_node *np, dma_addr_t *dma_addr,
+ phys_addr_t *paddr, phys_addr_t *size)
+{
+ struct device_node *node = np;
+ const u32 *ranges = NULL;
+ int len, naddr, nsize, pna;
+ int ret = 0;
+
+ if (!node)
+ return -EINVAL;
+
+ while (1) {
+ naddr = of_n_addr_cells(node);
+ nsize = of_n_size_cells(node);
+ node = of_get_next_parent(node);
+ if (!node)
+ break;
+
+ ranges = of_get_property(node, "dma-ranges", &len);
+
+ /* Ignore empty ranges, they imply no translation required */
+ if (ranges && len > 0)
+ break;
+
+ /*
+* At least empty ranges has to be defined for parent node if
+* DMA is supported
+*/
+ if (!ranges)
+ break;
+ }
+
+ if (!ranges) {
+ pr_debug("%s: no dma-ranges found for node(%s)\n",
+__func__, np->full_name);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ len /= sizeof(u32);
+
+ pna = of_n_addr_cells(node);
+
+ /* dma-ranges format:
+* DMA addr : naddr cells
+* CPU addr : pna cells
+* size : nsize cells
+*/
+ *dma_addr = of_read_number(ranges, naddr);
+ *paddr = of_translate_dma_address(np, ranges);
+ if (*paddr == OF_BAD_ADDR) {
+ pr_err("%s: translation of DMA address(%#08x) to CPU address
failed node(%s)\n",
+ __func__, *dma_addr, np->full_name);
+ ret = -EINVAL;
+ }
+
+ *size = of_read_number(ranges + naddr + pna, nsize);
+
+ pr_debug("dma_addr(%08x) cpu_addr(%pa) size(%pa)\n",
+*dma_addr, paddr, size);
+
+out:
+ of_node_put(node);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_dma_get_range);
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index ae36298..f04171a 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -41,6 +41,9 @@ extern struct dma_chan *of_dma_request_slave_channel(struct
device_node *np,
const char *name);
extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma);
+
+extern int of_dma_get_range(struct device_node *np, dma_addr_t *dma_addr,
+ phys_addr_t *paddr, phys_addr_t *size);
#else
static inline int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
@@ -66,6 +69,11 @@ static inline struct dma_chan *of_dma_simple_xlate(struct
of_phandle_args *dma_s
return NULL;
}
+static inline int of_dma_get_range(struct device_node *np, dma_addr_t
*dma_addr,
+ phys_addr_t *paddr, phys_addr_t *size);
+{
+ return -ENODEV;
+}
#endif
#endif /* __LINUX_OF_DMA_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 v2 7/7] ARM: dts: keystone: Udate USB node for dma properties
Keystone supports dma-coherent on USB master and also needs
dma-ranges to specify the hardware alias memory range in which DMA
can be operational.
Cc: Russell King
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Grant Likely
Cc: Rob Herring
Signed-off-by: Santosh Shilimkar
---
arch/arm/boot/dts/keystone.dtsi |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 171579d..de155c0 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -200,6 +200,8 @@
clock-names = "usb";
interrupts = ;
ranges;
+ dma-coherent;
+ dma-ranges;
status = "disabled";
dwc3@269 {
--
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 v2 5/7] ARM: of: introduce common routine for DMA configuration
From: Grygorii Strashko
This patch introduces ARM specific function arm_dt_dma_configure()
which intended to retrieve DMA configuration from DT and setup Platform
device's DMA parameters.
The DMA configuration in DT has to be specified using "dma-ranges"
and "dam-coherent" properties if supported. The DMA configuration applied
by arm_dt_dma_configure() as following:
- call of_get_dma_range() and get supported DMA range info
(dma_addr, cpu_addr, dma_size);
- if "not found" then fill dma_mask as DMA_BIT_MASK(32)
(this is default behaviour);
- if "failed" then clean up dma_mask (DMA not supported)
- if ok then update devices DMA configuration:
set dma_mask to (dma_addr + dma_size - 1)
set dma_pfn_offset to PFN_DOWN(cpu_addr - dma_addr)
Cc: Russell King
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Grant Likely
Cc: Rob Herring
Signed-off-by: Grygorii Strashko
Signed-off-by: Santosh Shilimkar
---
arch/arm/include/asm/prom.h |3 +++
arch/arm/kernel/devtree.c | 61 +++
drivers/of/platform.c |5 +++-
include/linux/of.h |2 +-
4 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index b681575..1acb732 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -11,11 +11,13 @@
#ifndef __ASMARM_PROM_H
#define __ASMARM_PROM_H
+struct device;
#ifdef CONFIG_OF
extern const struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
extern void arm_dt_memblock_reserve(void);
extern void __init arm_dt_init_cpu_maps(void);
+extern void arm_dt_dma_configure(struct device *dev);
#else /* CONFIG_OF */
@@ -26,6 +28,7 @@ static inline const struct machine_desc
*setup_machine_fdt(unsigned int dt_phys)
static inline void arm_dt_memblock_reserve(void) { }
static inline void arm_dt_init_cpu_maps(void) { }
+static inline void arm_dt_dma_configure(struct device *dev) { }
#endif /* CONFIG_OF */
#endif /* ASMARM_PROM_H */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index f751714..926b5dd 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -18,6 +18,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -235,3 +238,61 @@ const struct machine_desc * __init
setup_machine_fdt(unsigned int dt_phys)
return mdesc;
}
+
+void arm_dt_dma_configure(struct device *dev)
+{
+ dma_addr_t dma_addr;
+ phys_addr_t paddr, size;
+ dma_addr_t dma_mask;
+ int ret;
+
+ /*
+* if dma-ranges property doesn't exist - use 32 bits DMA mask
+* by default and don't set skip archdata.dma_pfn_offset
+*/
+ ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
+ if (ret == -ENODEV) {
+ dev->coherent_dma_mask = DMA_BIT_MASK(32);
+ if (!dev->dma_mask)
+ dev->dma_mask = &dev->coherent_dma_mask;
+ return;
+ }
+
+ /* if failed - disable DMA for device */
+ if (ret < 0) {
+ dev_err(dev, "failed to configure DMA\n");
+ return;
+ }
+
+ /* DMA ranges found. Calculate and set dma_pfn_offset */
+ dev->archdata.dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
+
+ /* Configure DMA mask */
+ dev->dma_mask = kmalloc(sizeof(*dev->dma_mask), GFP_KERNEL);
+ if (!dev->dma_mask)
+ return;
+
+ dma_mask = dma_addr + size - 1;
+
+ ret = arm_dma_set_mask(dev, dma_mask);
+ if (ret < 0) {
+ dev_err(dev, "failed to set DMA mask %#08x\n", dma_mask);
+ kfree(dev->dma_mask);
+ dev->dma_mask = NULL;
+ return;
+ }
+
+ dev_dbg(dev, "dma_pfn_offset(%#08lx) dma_mask(%#016llx)\n",
+ dev->archdata.dma_pfn_offset, *dev->dma_mask);
+
+ if (of_dma_is_coherent(dev->of_node)) {
+ set_dma_ops(dev, &arm_coherent_dma_ops);
+ dev_dbg(dev, "device is dma coherent\n");
+ }
+
+ ret = dma_set_coherent_mask(dev, dma_mask);
+ if (ret < 0) {
+ dev_err(dev, "failed to set coherent DMA mask %#08x\n",
+ dma_mask);
+ }
+}
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 404d1da..97d5533 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -213,10 +213,13 @@ static struct platform_device
*of_platform_device_create_pdata(
#if defined(CONFIG_MICROBLAZE)
dev->archdata.dma_mask = 0xUL;
-#endif
+#elif defined(CONFIG_ARM_LPAE)
+ arm_dt_dma_configure(&dev->dev);
+#else
dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
if (!dev->dev.dma_mask)
dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
+#endif
dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
diff --git a/include/linux/of.h b/inc
[PATCH v2 4/7] dma: of: introduce of_dma_is_coherent() helper
The of_dma_is_coherent() helper parses the given DT device
node to see if the "dma-coherent" property is supported and
returns true or false accordingly.
Cc: Russell King
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Grant Likely
Cc: Rob Herring
Signed-off-by: Santosh Shilimkar
---
drivers/dma/of-dma.c | 22 ++
include/linux/of_dma.h |5 +
2 files changed, 27 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 9b51768..c5958d1 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -304,3 +304,25 @@ out:
return ret;
}
EXPORT_SYMBOL_GPL(of_dma_get_range);
+
+/**
+ * of_dma_is_coherent - Check if device is coherent
+ * @np:device node
+ *
+ * It returns true if "dma-coherent" property was found
+ * for this device in DT.
+ */
+bool of_dma_is_coherent(struct device_node *np)
+{
+ struct device_node *node = np;
+
+ while (node) {
+ if (of_property_read_bool(node, "dma-coherent")) {
+ of_node_put(node);
+ return true;
+ }
+ node = of_get_next_parent(node);
+ }
+ return false;
+}
+EXPORT_SYMBOL_GPL(of_dma_is_coherent);
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index f04171a..6191f02 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -44,6 +44,7 @@ extern struct dma_chan *of_dma_simple_xlate(struct
of_phandle_args *dma_spec,
extern int of_dma_get_range(struct device_node *np, dma_addr_t *dma_addr,
phys_addr_t *paddr, phys_addr_t *size);
+extern bool of_dma_is_coherent(struct device_node *np);
#else
static inline int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
@@ -74,6 +75,10 @@ static inline int of_dma_get_range(struct device_node *np,
dma_addr_t *dma_addr,
{
return -ENODEV;
}
+static inline bool of_dma_is_coherent(struct device_node *np)
+{
+ return false;
+}
#endif
#endif /* __LINUX_OF_DMA_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 v2 1/7] ARM: mm: Introduce archdata.dma_pfn_offset
From: Grygorii Strashko
In most of cases DMA addresses can be performed using offset value of
Bus address space relatively to physical address space as following:
PFN->DMA:
__pfn_to_phys(pfn + [-]dma_pfn_offset)
DMA->PFN:
__phys_to_pfn(dma_addr) + [-]dma_pfn_offset
This patch introduces new field dma_pfn_offset in ARM dev_archdata
structure which has to be filed per-device at arch init time
(simplest way is to use Platform bus notifier to handle
BUS_NOTIFY_ADD_DEVICE event) and updates DMA address translation
routines in order to accommodate bus offset value by default.
Cc: Russell King
Cc: Arnd Bergmann
Cc: Olof Johansson
Signed-off-by: Grygorii Strashko
Signed-off-by: Santosh Shilimkar
---
arch/arm/include/asm/device.h |1 +
arch/arm/include/asm/dma-mapping.h | 17 +
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index dc662fc..861961c 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -8,6 +8,7 @@
struct dev_archdata {
struct dma_map_ops *dma_ops;
+ unsigned long dma_pfn_offset;
#ifdef CONFIG_DMABOUNCE
struct dmabounce_device_info *dmabounce;
#endif
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index e701a4d..247ed72 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -58,22 +58,31 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
#ifndef __arch_pfn_to_dma
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
- return (dma_addr_t)__pfn_to_bus(pfn);
+ if (!dev)
+ return DMA_ERROR_CODE;
+ return (dma_addr_t)__pfn_to_bus(pfn - dev->archdata.dma_pfn_offset);
}
static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
{
- return __bus_to_pfn(addr);
+ if (!dev)
+ return 0;
+ return __bus_to_pfn(addr) + dev->archdata.dma_pfn_offset;
}
static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
{
- return (void *)__bus_to_virt((unsigned long)addr);
+ if (!dev)
+ return NULL;
+ return (void *)__bus_to_virt(__pfn_to_bus(dma_to_pfn(dev, addr)));
}
static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
{
- return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
+ if (!dev)
+ return DMA_ERROR_CODE;
+ return pfn_to_dma(dev,
+ __bus_to_pfn(__virt_to_bus((unsigned long)(addr;
}
#else
--
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 v2 0/7] ARM: dma: Support dma-ranges and dma-coherent
Following the RFC [1], [2] comments, suggestions and some IRC discussion with Arnd Bergmann, here is the refreshed series. Attempt is to use dma-ranges and dma-coherent properties to setup the dma for ARM platforms. Platforms needing more funky stuff than the generic ones can use per platform device callbacks. Differnt buses like PCIE dma parsing still needs to be addressed though. Cc: Russell King Cc: Greg Ungerer Cc: Tony Lindgren Cc: Arnd Bergmann Cc: Olof Johansson CC: Grygorii Strashko Cc: Magnus Damm Cc: Linus Walleij Grygorii Strashko (5): ARM: mm: Introduce archdata.dma_pfn_offset ARM: mm: Remove unsed dma_to_virt() dma: of: introduce of_dma_get_range() helper ARM: of: introduce common routine for DMA configuration ARM: dts: keystone: Use dma-ranges property Santosh Shilimkar (2): dma: of: introduce of_dma_is_coherent() helper ARM: dts: keystone: Udate USB node for dma properties arch/arm/boot/dts/keystone.dtsi |3 + arch/arm/include/asm/device.h |1 + arch/arm/include/asm/dma-mapping.h | 25 +++ arch/arm/include/asm/prom.h |3 + arch/arm/kernel/devtree.c | 61 +++ arch/arm/mach-iop13xx/include/mach/memory.h | 11 --- arch/arm/mach-ks8695/include/mach/memory.h |2 - arch/arm/mach-omap1/include/mach/memory.h |4 - drivers/dma/of-dma.c| 108 +++ drivers/of/platform.c |5 +- include/linux/of.h |2 +- include/linux/of_dma.h | 13 12 files changed, 205 insertions(+), 33 deletions(-) Regards, Santosh [1] http://www.spinics.net/lists/arm-kernel/msg304555.html [2] http://www.spinics.net/lists/arm-kernel/msg310562.html -- 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 v12 1/4] PHY: Add function set_speed to generic PHY framework
Hi, >> >> This patch adds function set_speed to the generic PHY framework operation >> >> structure. This function can be called to instruct the PHY underlying >> >> layer >> >> at specified lane to configure for specified speed in hertz. >> > >> > why ? looks like clk_set_rate() is your friend here. Can you be more >> > descriptive of the use case ? When will this be used ? >> > >> >> The phy_set_speed is used to configure the operation speed of the PHY >> at run-time. The clock interface in general is used to configure the >> clock input to the IP. I don't believe they are the same thing. Maybe >> it will be clear in my response to your second email > > The problem with this is that you end up adding SATA-specific details to > something which is supposed to be generic. Setting the operation speed is pretty generic from an interface point of view. An generic multi-purpose PHY can support multiple speed. If the upper layer wish to operate at an specified speed (say for testing purpose and etc), it can be allowed. > After negoatiation, don't you > get any interrupt from your PHY indicating that link speed negotiation > is done ? Or is that IRQ only on AHCI IP ? There is NO interrupt from the PHY. The IRQ is assoicated with the AHCI IP. With SATA host flow, it starts off with an COMRESET to start the link negotiation. At that point, it will poll for completion. Any other concerns? -Loc -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/8] ARM: dts: omap3-overo: Use complete poweroff
+devicetree list.
On 02/27/2014 02:48 PM, Florian Vaussard wrote:
> On 02/27/2014 09:38 PM, Nishanth Menon wrote:
>> On 02/27/2014 02:30 PM, Florian Vaussard wrote:
>>> Currently, the TWL4030 PMIC does not completely poweroff the processor.
>>> Commit b0fc1da4d0359d3cce8f12e0f014aed0704ae202 introduced the necessary
>>> binding to do this, so use it.
>>>
>>> Signed-off-by: Florian Vaussard
>>> ---
>>> arch/arm/boot/dts/omap3-overo.dtsi | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
>>> b/arch/arm/boot/dts/omap3-overo.dtsi
>>> index aea64c0..018e1e0 100644
>>> --- a/arch/arm/boot/dts/omap3-overo.dtsi
>>> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
>>> @@ -73,6 +73,11 @@
>>> codec {
>>> };
>>> };
>>> +
>>> + twl_power: power {
>>> + compatible = "ti,twl4030-power";
>>> + ti,use_poweroff;
>>> + };
>>> };
>>> };
>>>
>>>
>> Urrgh.. this slipped past.. :(
>>
>> ti,system-power-controller is traditionally used for other PMICs from
>> TI to indicate that poweroff functionality will be provided by the
>> PMIC driver. similar approach is taken by Maxim as well.. I know the
>> commit introducing the binding has been around for long, but
>> considering that we do not have a single dts using this yet, should we
>> consider adding "ti,system-power-controller"(as against removing
>> ti,use_poweroff - so that older down stream dtbs still work) and using
>> it in the new code?
>>
>
> It does make sense, so I am not against it. My only concern is that I
> find the name to be slightly less easy to understand, but I can live
> with it :-)
:)
>
> I do not remember if DT maintainers came up with a clear policy to
> deprecate a binding.
I dont think we can depreciate a binding [1] - as you mentioned -
renaming the property is probably what is appropriate, but introducing
a new one which has the same behavior as the old one does'nt seem
covered either.. considering potential downstream kernel usage, I'd
suggest additional property inline with today's convention.
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a9330010bea5982a5c6593824bc036bf62d67b7
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework
Hi, On Thu, Feb 27, 2014 at 11:57:44AM -0800, Loc Ho wrote: > > On Thu, Feb 27, 2014 at 11:14:05AM -0700, Loc Ho wrote: > >> This patch adds function set_speed to the generic PHY framework operation > >> structure. This function can be called to instruct the PHY underlying layer > >> at specified lane to configure for specified speed in hertz. > > > > why ? looks like clk_set_rate() is your friend here. Can you be more > > descriptive of the use case ? When will this be used ? > > > > The phy_set_speed is used to configure the operation speed of the PHY > at run-time. The clock interface in general is used to configure the > clock input to the IP. I don't believe they are the same thing. Maybe > it will be clear in my response to your second email The problem with this is that you end up adding SATA-specific details to something which is supposed to be generic. After negoatiation, don't you get any interrupt from your PHY indicating that link speed negotiation is done ? Or is that IRQ only on AHCI IP ? cheers -- balbi signature.asc Description: Digital signature
[PATCH V2 3/3] ARM: tegra: fix Dalmore PMIC IRQ polarity
From: Stephen Warren
The Tegra PMC's resume-from-sleep logic wants an active-low IRQ input
from the PMIC. However, the PMIC IRQ is also routed to the GIC, which
only supports active high IRQs (or rising edge). Hence, the signal must
be inverted in the PMC before being routed to the GIC. This implies that
the PMC DT property nvidia,invert-interrupt must be set, and it is.
The PMIC's DT interrupts property must represent the IRQ level at the
GIC, since that is the PMIC's parent IRQ controller. Fix the PMIC's
interrupts property to correctly describe the GIC input polarity.
However, the PMIC IRQ output's polarity is programmable in HW, and by
default follows the parent IRQ controller's input polarity. We need to
have an active-low output due to the inversion inside the Tegra PMC.
Hence, add the ti,irq-externally-inverted property to the PMIC.
Reported-by: Stefan Agner
Signed-off-by: Stephen Warren
Acked-by: Laxman Dewangan
---
v2: No change.
---
arch/arm/boot/dts/tegra114-dalmore.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
b/arch/arm/boot/dts/tegra114-dalmore.dts
index 8de543777882..2977206cafc9 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -893,7 +893,8 @@
palmas: tps65913@58 {
compatible = "ti,palmas";
reg = <0x58>;
- interrupts = <0 86 IRQ_TYPE_LEVEL_LOW>;
+ interrupts = <0 86 IRQ_TYPE_LEVEL_HIGH>;
+ ti,irq-externally-inverted;
#interrupt-cells = <2>;
interrupt-controller;
--
1.8.1.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 V2 2/3] mfd: palmas: support IRQ inversion at the board level
From: Stephen Warren
Implement the new DT property ti,irq-externally-inverted, and add an
equivalent platform data field to match. This allows the driver to
correctly automatically configure the IRQ output polarity when the board
or SoC contains an inverter between the Palmas IRQ output and IRQ
controller input.
Signed-off-by: Stephen Warren
Acked-by: Laxman Dewangan
Acked-by: Lee Jones
---
v2: Split V1's patch 1/2 into separate patches 1/3 and 2/3.
If this patch (and likely 1/3 too) could be applied to its own branch
(w/ signed tag) in the MFD tree, that would great; then I can pull patch
it into the Tegra tree so that I can apply patch 3/3 on top. Thanks.
---
drivers/mfd/palmas.c | 4
include/linux/mfd/palmas.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index d280d789e55a..f4ea932adf8d 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -293,6 +293,8 @@ static int palmas_set_pdata_irq_flag(struct i2c_client *i2c,
}
pdata->irq_flags = irqd_get_trigger_type(irq_data);
+ pdata->irq_external_inversion = of_property_read_bool(i2c->dev.of_node,
+ "ti,irq-externally-inverted");
dev_info(&i2c->dev, "Irq flag is 0x%08x\n", pdata->irq_flags);
return 0;
}
@@ -447,6 +449,8 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
reg = PALMAS_POLARITY_CTRL_INT_POLARITY;
else
reg = 0;
+ if (pdata->irq_external_inversion)
+ reg ^= PALMAS_POLARITY_CTRL_INT_POLARITY;
ret = palmas_update_bits(palmas, PALMAS_PU_PD_OD_BASE,
PALMAS_POLARITY_CTRL, PALMAS_POLARITY_CTRL_INT_POLARITY,
reg);
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 9974e387e483..2fdf08c50a48 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -292,6 +292,7 @@ struct palmas_clk_platform_data {
struct palmas_platform_data {
int irq_flags;
+ bool irq_external_inversion;
int gpio_base;
/* bit value to be loaded to the POWER_CTRL register */
--
1.8.1.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 V2 1/3] dt: palmas: support IRQ inversion at the board level
From: Stephen Warren Some boards or SoCs have an inverter between the PMIC IRQ output pin and the IRQ controller input signal. The IRQ specifier in DT is meant to represent the IRQ flags at the input to the IRQ controller. The Palmas HW's IRQ output has configurable polarity. Software needs to know which polarity to choose for the IRQ output. Software may be tempted to extract the IRQ polarity from the IRQ specifier in order to make this choice. That approach works fine if the IRQ signal is routed directly from the PMIC to the IRQ controller with no intervening logic. However, if the signal is inverted between the two, this approach gets the wrong answer. Add an additional optional DT property which indicates that such an inversion occurs. This allows DT to give complete information about the desired IRQ output polarity to software. An alternative would have been to add a new non-optional DT parameter to indicate the exact desired output polarity. However, this would have been an incompatible change to the DT binding. Signed-off-by: Stephen Warren Acked-by: Laxman Dewangan Acked-by: Lee Jones --- v2: Split V1's patch 1/2 into separate patches 1/3 and 2/3. --- Documentation/devicetree/bindings/mfd/palmas.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index e5f0f8303461..76ec509d5f87 100644 --- a/Documentation/devicetree/bindings/mfd/palmas.txt +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -18,6 +18,12 @@ Required properties: ti,tps659038 and also the generic series names ti,palmas +- interrupts : Should contain a single entry for the IRQ output. +- ti,irq-externally-inverted : If missing, the polarity of the Palmas IRQ + output should be set to the opposite of the polarity indicated by the IRQ + specifier in the interrupts property. If absent, the polarity should be + configured to match. This allows the representation of an inverter between + the Palmas IRQ output and the interrupt parent's IRQ input. - interrupt-controller : palmas has its own internal IRQs - #interrupt-cells : should be set to 2 for IRQ number and flags The first cell is the IRQ number. -- 1.8.1.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 v2 05/31] sandbox: dts: Add display and keyboard to sandbox
Add an LCD display and keyboard to the sandbox device tree so that these
features can be used.
Signed-off-by: Simon Glass
---
Changes in v2: None
arch/sandbox/dts/sandbox.dts | 95
1 file changed, 95 insertions(+)
diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index ea4b8ad..11afbc2 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -27,4 +27,99 @@
sides = <6>;
};
+ host@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "sandbox,host-emulation";
+ cros-ec@0 {
+ reg = <0>;
+ compatible = "google,cros-ec";
+
+ /*
+* This describes the flash memory within the EC. Note
+* that the STM32L flash erases to 0, not 0xff.
+*/
+ #address-cells = <1>;
+ #size-cells = <1>;
+ flash@800 {
+ reg = <0x0800 0x2>;
+ erase-value = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* Information for sandbox */
+ ro {
+ reg = <0 0xf000>;
+ };
+ wp-ro {
+ reg = <0xf000 0x1000>;
+ };
+ rw {
+ reg = <0x1 0x1>;
+ };
+ };
+ };
+ };
+
+ lcd {
+ compatible = "sandbox,lcd-sdl";
+ xres = <800>;
+ yres = <600>;
+ };
+
+ cros-ec-keyb {
+ compatible = "google,cros-ec-keyb";
+ google,key-rows = <8>;
+ google,key-columns = <13>;
+ google,repeat-delay-ms = <240>;
+ google,repeat-rate-ms = <30>;
+ google,ghost-filter;
+ /*
+* Keymap entries take the form of 0xRRCC where
+* RR=Row CC=Column =Key Code
+* The values below are for a US keyboard layout and
+* are taken from the Linux driver. Note that the
+* 102ND key is not used for US keyboards.
+*/
+ linux,keymap = <
+ /* CAPSLCK F1 B F10 */
+ 0x0001003a 0x0002003b 0x00030030 0x00040044
+ /* N = R_ALT ESC */
+ 0x00060031 0x0008000d 0x000a0064 0x01010001
+ /* F4 G F7 H */
+ 0x0102003e 0x01030022 0x01040041 0x01060023
+ /* ' F9 BKSPACEL_CTRL */
+ 0x01080028 0x01090043 0x010b000e 0x021d
+ /* TAB F3 T F6 */
+ 0x0201000f 0x0202003d 0x02030014 0x02040040
+ /* ] Y 102ND [ */
+ 0x0205001b 0x02060015 0x02070056 0x0208001a
+ /* F8 GRAVE F2 5 */
+ 0x02090042 0x03010029 0x0302003c 0x03030006
+ /* F5 6 - \ */
+ 0x0304003f 0x03060007 0x0308000c 0x030b002b
+ /* R_CTRL A D F */
+ 0x0461 0x0401001e 0x04020020 0x04030021
+ /* S K J ; */
+ 0x0404001f 0x04050025 0x04060024 0x04080027
+ /* L ENTER Z C */
+ 0x04090026 0x040b001c 0x0501002c 0x0502002e
+ /* V X , M */
+ 0x0503002f 0x0504002d 0x05050033 0x05060032
+ /* L_SHIFT / . SPACE */
+ 0x0507002a 0x05080035 0x05090034 0x050B0039
+ /* 1 3 4 2 */
+ 0x06010002 0x06020004 0x06030005 0x06040003
+ /* 8 7 0 9 */
+ 0x06050009 0x06060008 0x0608000b 0x0609000a
+ /* L_ALT DOWN RIGHT Q */
+ 0x060a0038 0x060b006c 0x060c006a 0x07010010
+ /* E R W I */
+ 0x07020012 0x07030013 0x07040011 0x07050017
+ /* U R_
[PATCH v2 0/31] Add additional sandbox features and infrastructure
At present sandbox only supports a basic set of features. To help address this, a recent series added SPI and SPI flash support; this series expands the coverage further. Firstly SDL is used to provide LCD and audio support. Sandbox gains its own LCD driver which can display images, host a command line, etc. The audio support is basic and needs additional work, but it is a starting point. SDL also provides a keyboard emulation (using the Chrome OS EC code as a base). Secondly a TPM emulation is added. This does not include all features (the implementation is quite simplistic) but it is enough to do basic secure boot operations. Finally, various pieces of useful infrastructure are added, including: - loading and saving of the emulated SDRAM to permit test runs to carry over state - loading and saving of general sandbox state (for example a driver can save its stage and reload it on the next run) - support for using bootm to load a kernel - providing a device tree for use by sandbox - a means to jump to another U-Boot while preserving state (useful for test environments which want to run a series of tests with script-selectable state) Major functions which still remain without sandbox support are I2C, networking and USB. Note: Much of this series was sent out in November. Due to problems with the LCD side it was not ready for the last release, although about a dozen patches from the series were applied. I have rebased and tidied things up. U-Boot now starts by default without the LCD visible since for much sandbox testing we don't want the LCD. The Chrome OS EC code has been updated and tidied up and full keyboard support is now present in the LCD window. Changes in v2: - Add new patch to adjust #ifdef position in cros_ec - Add new patch to sync with latest Chrome OS EC version - Add new patches to bring in protocol v3 support - Rebase to master - Update series to take account of patches now merges from original series Randall Spangler (2): cros_ec: Clean up multiple EC protocol support cros_ec: spi: Add support for EC protocol version 3 Simon Glass (27): Use a const pointer for map_to_sysmem() sandbox: Increase memory size to 32MB sandbox: Build a device tree file for sandbox sandbox: Use os functions to read host device tree sandbox: dts: Add display and keyboard to sandbox cros_ec: Add an enum for the number of flash regions cros_ec: Add a function for reading a flash map entry cros_ec: Add a function for decoding the Chrome OS EC flashmap cros_ec: Support systems with no EC interrupt cros_ec: Move #ifdef to permit flash region access cros_ec: Sync up with latest Chrome OS EC version cros_ec: Add base support for protocol v3 cros_ec: Correct comparison between signed and unsigned numbers cros_ec: sandbox: Add Chrome OS EC emulation sandbox: Plumb in Chrome OS EC emulation cros_ec: Implement I2C pass-through sandbox: Add os_jump_to_image() to run another executable sandbox: Add -j option to indicate a jump from a previous U-Boot sandbox: Add SDL library for LCD, keyboard, audio sandbox: Add a simple sound driver sandbox: Add LCD driver sound: Move Samsung-specific code into its own file sandbox: Deal with conflicting getenv() for SDL sandbox: Allow Ctrl-C to work in sandbox sandbox: Add options to clean up temporary files sandbox: Add implementation of spi_setup_slave_fdt() sandbox: config: Enable cros_ec emulation and related items Vadim Bendebury (2): cros_ec: Move EC interface into common library cros_ec: Drop old EC version support from EC driver Makefile | 3 +- arch/sandbox/config.mk| 5 + arch/sandbox/cpu/Makefile | 3 + arch/sandbox/cpu/cpu.c| 2 +- arch/sandbox/cpu/os.c | 108 - arch/sandbox/cpu/sdl.c| 341 ++ arch/sandbox/cpu/start.c | 60 +++ arch/sandbox/cpu/state.c | 6 +- arch/sandbox/dts/Makefile | 11 + arch/sandbox/dts/sandbox.dts | 125 ++ arch/sandbox/include/asm/arch-sandbox/sound.h | 14 + arch/sandbox/include/asm/sdl.h| 118 + arch/sandbox/include/asm/state.h | 29 +- arch/sandbox/include/asm/u-boot-sandbox.h | 3 + board/samsung/common/board.c | 29 +- board/samsung/smdk5250/exynos5-dt.c | 1 - board/sandbox/sandbox/sandbox.c | 49 ++- common/Makefile | 1 + common/board_f.c | 48 +- common/cros_ec.c | 44 ++ common/lcd.c | 21 +- disk/part.c | 17 - doc/device-tree-bindings/video/sandbox-fb.txt | 13 + drivers/input/cros_ec_keyb.c | 34 +- drivers/misc/Makefile |
Re: [PATCH] checkpatch: fix spurious vendor compatible warnings
On 02/27/2014 09:10 PM, Joe Perches wrote:
> On Thu, 2014-02-27 at 20:56 +0100, Florian Vaussard wrote:
>> With a compatible string like
>>
>> compatible = "foo";
>>
>> checkpatch will currently try to find "foo" in vendor-prefixes.txt,
>> which is wrong since the vendor prefix is empty in this specific case.
>>
>> Skip the vendor test if the compatible is not like
>>
>> compatible = "vendor,something";
>>
>> Signed-off-by: Florian Vaussard
>> ---
>> scripts/checkpatch.pl | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
>> index 464dcef..35ec185 100755
>> --- a/scripts/checkpatch.pl
>> +++ b/scripts/checkpatch.pl
>> @@ -2058,6 +2058,7 @@ sub process {
>> my $vendor = $compat;
>> my $vendor_path = $dt_path .
>> "vendor-prefixes.txt";
>> next if (! -f $vendor_path);
>> +next if not $vendor =~ /^[a-zA-Z0-9]+\,.*/;
>> $vendor =~ s/^([a-zA-Z0-9]+)\,.*/$1/;
>> `grep -Eq "$vendor" $vendor_path`;
>> if ( $? >> 8 ) {
>
> Some vendor names have dashes.
> I don't know if underscores are allowed.
>
> $ grep -rP --include=*.[ch] -oh "compatible\s*=\s*\"[^,]+,\w" * | \
> sed -r -e 's/\s//g' -e 's/,.$//' | sort | uniq -c | grep "[_-]"
> 1 compatible="active-semi
> 8 compatible="asahi-kasei
>
Good catch. In ePAPR v1.1, I could not find any strict requirement. It
is just saying:
The recommended format is “manufacturer,model”, where manufacturer is a
string describing the name of the manufacturer (such as a stock ticker
symbol), and model specifies the model number.
If I am not mistaking, the stock ticker symbol will not contain exotic
characters, but it is not always available. So we should probably add
the '-. I am not sure for the '_'.
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] pci: OF: Fix the conversion of IO ranges into IO resources.
On Thursday 27 February 2014 13:07:29 Jason Gunthorpe wrote: > On Thu, Feb 27, 2014 at 08:48:08PM +0100, Arnd Bergmann wrote: > > > It also looks correct for architectures that use the CPU MMIO address > > > as the IO address directly (where IO_SPACE_LIMIT would be 4G) > > > > Are you aware of any that still do? I thought we had stopped doing > > that. > > I thought ia64 used to, but it has been a long time since I've touched > one... They have a different way of doing it now, no idea how it looked in the past: #define IO_SPACE_LIMIT 0xUL #define MAX_IO_SPACES_BITS 8 #define MAX_IO_SPACES (1UL << MAX_IO_SPACES_BITS) #define IO_SPACE_BITS 24 #define IO_SPACE_SIZE (1UL << IO_SPACE_BITS) #define IO_SPACE_NR(port) ((port) >> IO_SPACE_BITS) #define IO_SPACE_BASE(space)((space) << IO_SPACE_BITS) #define IO_SPACE_PORT(port) ((port) & (IO_SPACE_SIZE - 1)) #define IO_SPACE_SPARSE_ENCODING(p) p) >> 2) << 12) | ((p) & 0xfff)) So their port number is a logical token that contains the I/O space number and a 16MB offset. Apparently sparc64 uses physical memory addressing for I/O space, the same way they do for memory space, and they just set IO_SPACE_LIMIT to 0xUL. > > > Architectures that use the virtual IO window technique will always > > > require a custom pci_address_to_pio implementation. > > > > Hmm, at the moment we only call it from of_address_to_resource(), > > which in turn does not get called on PCI devices, and does not > > call pci_address_to_pio for 'simple' platform devices. The only > > case I can think of where it actually matters is when we have > > ISA devices in DT that use an I/O port address in the reg property, > > and that case hopefully won't happen on ARM32 or ARM64. > > Sure, I ment, after Liviu's patch it will become required since he is > cleverly using it to figure out what the io mapping the bridge driver > setup before calling the helper. Ok. I was arguing more that we should add this dependency. > > > I think the legacy reasons for having all those layers of translation > > > are probably not applicable to ARM64, and it is much simpler without > > > the extra translation step > > > > > > Arnd, what do you think? > > > > Either I don't like it or I misunderstand you ;-) > > > > Most PCI drivers normally don't call ioport_map or pci_iomap, so > > we can't just do it there. If you are thinking of calling ioport_map > > Okay, that was one of the 'legacy reasons'. Certainly lots of drivers > do call pci_iomap, but if you think legacy drivers that don't are > important to ARM64 then it makes sense to use the virtual IO window. I think all uses of I/O space are legacy, but I don't think that drivers doing inb/outb are more obsolete than those doing pci_iomap. It's got more to do with the subsystem requirements, e.g. libata requires the use of pci_iomap. > > for every PCI device that has an I/O BAR and storing the virtual > > address in the pci_dev resource, I don't see what that gains us > > Mainly we get to drop the fancy dynamic allocation stuff for the fixed > virtual window, and it gives the option to have a 1:1 relationship > between CPU addresses and PCI BARs. I don't think the allocation is much of a problem, as long as we can localize it in one function that is shared by everyone. The problems I saw were all about explaining to people how it works, but they really shouldn't have to know. 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] of: add vendor prefix for SMSC
Add a vendor prefix for Standard Microsystems Corporation, now part of Microchip. Signed-off-by: Florian Vaussard --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 40ce2df..7187c71 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -80,6 +80,7 @@ sil Silicon Image silabs Silicon Laboratories simtek sirf SiRF Technology, Inc. +smsc Standard Microsystems Corporation snps Synopsys, Inc. spansion Spansion Inc. st STMicroelectronics -- 1.8.5.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] checkpatch: fix spurious vendor compatible warnings
On Thu, 2014-02-27 at 20:56 +0100, Florian Vaussard wrote:
> With a compatible string like
>
> compatible = "foo";
>
> checkpatch will currently try to find "foo" in vendor-prefixes.txt,
> which is wrong since the vendor prefix is empty in this specific case.
>
> Skip the vendor test if the compatible is not like
>
> compatible = "vendor,something";
>
> Signed-off-by: Florian Vaussard
> ---
> scripts/checkpatch.pl | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 464dcef..35ec185 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2058,6 +2058,7 @@ sub process {
> my $vendor = $compat;
> my $vendor_path = $dt_path .
> "vendor-prefixes.txt";
> next if (! -f $vendor_path);
> + next if not $vendor =~ /^[a-zA-Z0-9]+\,.*/;
> $vendor =~ s/^([a-zA-Z0-9]+)\,.*/$1/;
> `grep -Eq "$vendor" $vendor_path`;
> if ( $? >> 8 ) {
Some vendor names have dashes.
I don't know if underscores are allowed.
$ grep -rP --include=*.[ch] -oh "compatible\s*=\s*\"[^,]+,\w" * | \
sed -r -e 's/\s//g' -e 's/,.$//' | sort | uniq -c | grep "[_-]"
1 compatible="active-semi
8 compatible="asahi-kasei
--
To unsubscribe from this list: send the line "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/4] pci: OF: Fix the conversion of IO ranges into IO resources.
On Thu, Feb 27, 2014 at 08:48:08PM +0100, Arnd Bergmann wrote: > > It also looks correct for architectures that use the CPU MMIO address > > as the IO address directly (where IO_SPACE_LIMIT would be 4G) > > Are you aware of any that still do? I thought we had stopped doing > that. I thought ia64 used to, but it has been a long time since I've touched one... > > Architectures that use the virtual IO window technique will always > > require a custom pci_address_to_pio implementation. > > Hmm, at the moment we only call it from of_address_to_resource(), > which in turn does not get called on PCI devices, and does not > call pci_address_to_pio for 'simple' platform devices. The only > case I can think of where it actually matters is when we have > ISA devices in DT that use an I/O port address in the reg property, > and that case hopefully won't happen on ARM32 or ARM64. Sure, I ment, after Liviu's patch it will become required since he is cleverly using it to figure out what the io mapping the bridge driver setup before calling the helper. > > I think the legacy reasons for having all those layers of translation > > are probably not applicable to ARM64, and it is much simpler without > > the extra translation step > > > > Arnd, what do you think? > > Either I don't like it or I misunderstand you ;-) > > Most PCI drivers normally don't call ioport_map or pci_iomap, so > we can't just do it there. If you are thinking of calling ioport_map Okay, that was one of the 'legacy reasons'. Certainly lots of drivers do call pci_iomap, but if you think legacy drivers that don't are important to ARM64 then it makes sense to use the virtual IO window. > for every PCI device that has an I/O BAR and storing the virtual > address in the pci_dev resource, I don't see what that gains us Mainly we get to drop the fancy dynamic allocation stuff for the fixed virtual window, and it gives the option to have a 1:1 relationship between CPU addresses and PCI BARs. > in terms of complexity, and it will also break /dev/port. Yes, /dev/port needs updating, it would need to iomap (arguably it probably should be doing that already anyhow), and the hardwired limit of 65536 needs to be replaced with the arch's IO limit, but those do not seem to be fundemental problems with the UAPI?? 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 2/4] net: rfkill: gpio: remove gpio names
On Thu, Feb 27, 2014 at 10:47:58AM -0700, Stephen Warren wrote:
> On 02/27/2014 10:38 AM, Gross, Mark wrote:
> > Please know that no one should not consider me an authority on ACPI at this
> > time. But, I have some comments / context / thoughts below.
> >
> > Also I apologize in advance for any email formatting issues caused by
> > replying to this via my work exchange account / outlook client. Folks can
> > use mgr...@linux.intel.com to avoid outlook-isms from me in the future.
> >
> >> -Original Message-
> >> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> >> Sent: Tuesday, February 25, 2014 1:14 AM
> >> To: Stephen Warren; Alexandre Courbot; Grant Likely;
> >> devicetree@vger.kernel.org
> >> Cc: Chen-Yu Tsai; Heikki Krogerus; Johannes Berg; David S. Miller; Rhyland
> >> Klein; linux-wireless; netdev; linux-kernel; Arnd Bergmann; Gross, Mark
> >> Subject: Re: [PATCH 2/4] net: rfkill: gpio: remove gpio names
> >>
> >> On Fri, Feb 21, 2014 at 6:35 AM, Stephen Warren
> >> wrote:
> >>> On 02/20/2014 06:55 PM, Chen-Yu Tsai wrote:
> >>
> That's correct. However using con_id to pass this results in
> different behavior across DT and ACPI. A better way is to export the
> labeling function so consumers can set meaningful labels themselves.
> >>>
> >>> But this code is the consumer of those GPIOs. IF the parameter to
> >>> devm_gpiod_get_index() isn't intended to be used, why does it exist?
> >>
> >> Kerneldoc says:
> >>
> >> /**
> >> * gpiod_get_index - obtain a GPIO from a multi-index GPIO function
> >> * @dev:GPIO consumer, can be NULL for system-global GPIOs
> >> * @con_id: function within the GPIO consumer
> >> * @idx:index of the GPIO to obtain in the consumer
> >> *
> >>
> >> Basically it is just exposing the fact that of_find_gpio() and
> >> acpi_find_gpio() both take a con_id as argument.
> >>
> >> If we drill into this, we find that it is used to conjure the arbitrary
> >> string
> >> before the gpios in the DT case, like:
> >>
> >> foo-gpios = <...>;
> >>
> >> As in tegra30-beaver.dts...
> >>
> >> sdhci@7800 {
> >> status = "okay";
> >> cd-gpios = <&gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
> >> wp-gpios = <&gpio TEGRA_GPIO(T, 3) GPIO_ACTIVE_HIGH>;
> >> power-gpios = <&gpio TEGRA_GPIO(D, 7) GPIO_ACTIVE_HIGH>;
> >> bus-width = <4>;
> >> };
> >>
> >> Instead of passing the GPIOs as index 0,1,2 they are named and I do admit
> >> this has a nice "things are under control" aspect to it.
> >
> > [Gross, Mark] FWIW I don't think this is as "under control" as you do.
> > Those
> > names in the above sdhci example are derived from a specific SDHCI
> tegra spec
> > sheet or schematic. Those names likely come from the data sheet for
> > the controller.
>
> The names of the properties are fixed and defined by the DT binding for
> the Tegra SDHCI controller, or even the core SDHCI bindings. Hence, they
> will be the same in every DT file that uses that Tegra SDHCI compatible
> value (the compatible property isn't show above, because the above
> fragment is a board.dts file, and the compatible value gets inherited
> from the soc.dtsi file). There won't be any variation at all,
> irrespective of what signal names exist in a particular board schematic.
>
> If there were ever an (upstream?) ACPI "binding"(?) for the Tegra SDHCI
> controller, I would hope it would use the exact same names for the GPIO
> signals.
me to!
--mark
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 3/4] PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
Hi Balbi, >> +/* >> + * This function is used to configure the PHY to operation as either SATA >> Gen1 >> + * or Gen2 speed. >> + */ >> +static void xgene_phy_sata_force_gen(struct xgene_phy_ctx *ctx, >> + int lane, int gen) > > why do you need to *force* the generation ? Is this because of some > silicon errata ? It almost seems like this should be done through link > negotiation between both link partners. You can call this as an errata or limitation of the underlying PHY IP. As start, the PHY is configured with auto neg up to 6Gbps (or Gen3 speed). After link up, we will know whether it is Gen1 (1.5Gbps), Gen2 (3.0Gbps), or Gen3 (6.0Gbps). In order to ensure reliability, the PHY needs to be configured at specified speed. For this reason and after link up, the PHY is re-trained for the linked up speed. -Loc -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework
Hi Balbi, > On Thu, Feb 27, 2014 at 11:14:05AM -0700, Loc Ho wrote: >> This patch adds function set_speed to the generic PHY framework operation >> structure. This function can be called to instruct the PHY underlying layer >> at specified lane to configure for specified speed in hertz. > > why ? looks like clk_set_rate() is your friend here. Can you be more > descriptive of the use case ? When will this be used ? > The phy_set_speed is used to configure the operation speed of the PHY at run-time. The clock interface in general is used to configure the clock input to the IP. I don't believe they are the same thing. Maybe it will be clear in my response to your second email -Loc -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] checkpatch: fix spurious vendor compatible warnings
With a compatible string like
compatible = "foo";
checkpatch will currently try to find "foo" in vendor-prefixes.txt,
which is wrong since the vendor prefix is empty in this specific case.
Skip the vendor test if the compatible is not like
compatible = "vendor,something";
Signed-off-by: Florian Vaussard
---
scripts/checkpatch.pl | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 464dcef..35ec185 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2058,6 +2058,7 @@ sub process {
my $vendor = $compat;
my $vendor_path = $dt_path .
"vendor-prefixes.txt";
next if (! -f $vendor_path);
+ next if not $vendor =~ /^[a-zA-Z0-9]+\,.*/;
$vendor =~ s/^([a-zA-Z0-9]+)\,.*/$1/;
`grep -Eq "$vendor" $vendor_path`;
if ( $? >> 8 ) {
--
1.8.5.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/4] pci: OF: Fix the conversion of IO ranges into IO resources.
On Thursday 27 February 2014 12:36:27 Jason Gunthorpe wrote: > On Thu, Feb 27, 2014 at 07:12:59PM +, Liviu Dudau wrote: > > The outstanding issue is how to fix pci_address_to_pio() as it will not > > for for range->cpu_addr > IO_SPACE_LIMIT (16MB in my case). > > The default actually looks fine to me, it is the correct behavior for > systems that actually have a dedicated IO space (like x86) where the > 'CPU' value for IO is the exact value used in the IO accessor > instructions. In this case the IO_SPACE_LIMIT test is appropriate. Right. > It also looks correct for architectures that use the CPU MMIO address > as the IO address directly (where IO_SPACE_LIMIT would be 4G) Are you aware of any that still do? I thought we had stopped doing that. > Architectures that use the virtual IO window technique will always > require a custom pci_address_to_pio implementation. Hmm, at the moment we only call it from of_address_to_resource(), which in turn does not get called on PCI devices, and does not call pci_address_to_pio for 'simple' platform devices. The only case I can think of where it actually matters is when we have ISA devices in DT that use an I/O port address in the reg property, and that case hopefully won't happen on ARM32 or ARM64. > BTW, something that occured to me after reading the patches: > > For ARM64 you might want to think about doing away with the fixed > virtual IO window like we see in ARM32. Just use the CPU MMIO address > directly within the kernel, and implement a ioport_map to setup the MM > on demand. > > I think the legacy reasons for having all those layers of translation > are probably not applicable to ARM64, and it is much simpler without > the extra translation step > > Arnd, what do you think? Either I don't like it or I misunderstand you ;-) Most PCI drivers normally don't call ioport_map or pci_iomap, so we can't just do it there. If you are thinking of calling ioport_map for every PCI device that has an I/O BAR and storing the virtual address in the pci_dev resource, I don't see what that gains us in terms of complexity, and it will also break /dev/port. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] pci: OF: Fix the conversion of IO ranges into IO resources.
On Thu, Feb 27, 2014 at 07:12:59PM +, Liviu Dudau wrote: > The outstanding issue is how to fix pci_address_to_pio() as it will not > for for range->cpu_addr > IO_SPACE_LIMIT (16MB in my case). The default actually looks fine to me, it is the correct behavior for systems that actually have a dedicated IO space (like x86) where the 'CPU' value for IO is the exact value used in the IO accessor instructions. In this case the IO_SPACE_LIMIT test is appropriate. It also looks correct for architectures that use the CPU MMIO address as the IO address directly (where IO_SPACE_LIMIT would be 4G) Architectures that use the virtual IO window technique will always require a custom pci_address_to_pio implementation. BTW, something that occured to me after reading the patches: For ARM64 you might want to think about doing away with the fixed virtual IO window like we see in ARM32. Just use the CPU MMIO address directly within the kernel, and implement a ioport_map to setup the MM on demand. I think the legacy reasons for having all those layers of translation are probably not applicable to ARM64, and it is much simpler without the extra translation step Arnd, what do you think? 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
[PATCH v4 2/3] ARM: sun7i/sun6i: dts: Add NMI irqchip support
This patch adds DTS entries for NMI controller as child of GIC.
Signed-off-by: Carlo Caione
---
arch/arm/boot/dts/sun6i-a31.dtsi | 9 +
arch/arm/boot/dts/sun7i-a20.dtsi | 9 +
2 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 5256ad9..4a5050c 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -190,6 +190,15 @@
#size-cells = <1>;
ranges;
+ nmi_intc: sc-nmi-intc@01f00c0c {
+ compatible = "allwinner,sun6i-a31-sc-nmi";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x01f00c0c 0x38>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 0 4>;
+ };
+
pio: pinctrl@01c20800 {
compatible = "allwinner,sun6i-a31-pinctrl";
reg = <0x01c20800 0x400>;
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 4c25f81..f01a23c 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -310,6 +310,15 @@
#size-cells = <1>;
ranges;
+ nmi_intc: sc-nmi-intc@01c00030 {
+ compatible = "allwinner,sun7i-a20-sc-nmi";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x01c00030 0x0c>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 0 4>;
+ };
+
emac: ethernet@01c0b000 {
compatible = "allwinner,sun4i-emac";
reg = <0x01c0b000 0x1000>;
--
1.8.3.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 v4 0/3] ARM: sun7i/sun6i: irqchip: Irqchip driver for NMI
Allwinner A20/A31 SoCs have a special interrupt controller for managing NMI. Three register are present to (un)mask, control and acknowledge NMI. These two patches add a new irqchip driver in cascade with GIC. Changes since v1: - added binding document Changes since v2: - fixed trigger type in DTS - new explanations in binding documentation - added support for A31 (sun6i) Changes since v3: - changed compatibles Carlo Caione (3): ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller ARM: sun7i/sun6i: dts: Add NMI irqchip support ARM: sun7i/sun6i: irqchip: Update the documentation .../allwinner,sun67i-sc-nmi.txt| 27 +++ arch/arm/boot/dts/sun6i-a31.dtsi | 9 + arch/arm/boot/dts/sun7i-a20.dtsi | 9 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-sunxi-nmi.c| 228 + 5 files changed, 274 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt create mode 100644 drivers/irqchip/irq-sunxi-nmi.c -- 1.8.3.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 v4 1/3] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
Allwinner A20/A31 SoCs have special registers to control / (un)mask /
acknowledge NMI. This NMI controller is separated and independent from GIC.
This patch adds a new irqchip to manage NMI.
Signed-off-by: Carlo Caione
---
drivers/irqchip/Makefile| 1 +
drivers/irqchip/irq-sunxi-nmi.c | 228
2 files changed, 229 insertions(+)
create mode 100644 drivers/irqchip/irq-sunxi-nmi.c
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index c60b901..e31d4d6 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_METAG_PERFCOUNTER_IRQS) += irq-metag.o
obj-$(CONFIG_ARCH_MOXART) += irq-moxart.o
obj-$(CONFIG_ORION_IRQCHIP)+= irq-orion.o
obj-$(CONFIG_ARCH_SUNXI) += irq-sun4i.o
+obj-$(CONFIG_ARCH_SUNXI) += irq-sunxi-nmi.o
obj-$(CONFIG_ARCH_SPEAR3XX)+= spear-shirq.o
obj-$(CONFIG_ARM_GIC) += irq-gic.o
obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
diff --git a/drivers/irqchip/irq-sunxi-nmi.c b/drivers/irqchip/irq-sunxi-nmi.c
new file mode 100644
index 000..8796ae0
--- /dev/null
+++ b/drivers/irqchip/irq-sunxi-nmi.c
@@ -0,0 +1,228 @@
+/*
+ * Allwinner A20/A31 SoCs NMI IRQ chip driver.
+ *
+ * Carlo Caione
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "irqchip.h"
+
+#define SUNXI_NMI_SRC_TYPE_MASK0x0003
+
+enum {
+ SUNXI_SRC_TYPE_LEVEL_LOW = 0,
+ SUNXI_SRC_TYPE_EDGE_FALLING,
+ SUNXI_SRC_TYPE_LEVEL_HIGH,
+ SUNXI_SRC_TYPE_EDGE_RISING,
+};
+
+struct sunxi_sc_nmi_reg_offs {
+ u32 ctrl;
+ u32 pend;
+ u32 enable;
+};
+
+static struct sunxi_sc_nmi_reg_offs sun7i_reg_offs = {
+ .ctrl = 0x00,
+ .pend = 0x04,
+ .enable = 0x08,
+};
+
+static struct sunxi_sc_nmi_reg_offs sun6i_reg_offs = {
+ .ctrl = 0x00,
+ .pend = 0x04,
+ .enable = 0x34,
+};
+
+/*
+ * Ack level interrupts right before unmask
+ *
+ * In case of level-triggered interrupt, IRQ line must be acked before it
+ * is unmasked or else a double-interrupt is triggered
+ */
+
+static void sunxi_sc_nmi_ack_and_unmask(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+ u32 mask = d->mask;
+
+ if (irqd_get_trigger_type(d) & IRQ_TYPE_LEVEL_MASK)
+ ct->chip.irq_ack(d);
+
+ irq_gc_lock(gc);
+ irq_reg_writel(mask, gc->reg_base + ct->regs.mask);
+ irq_gc_unlock(gc);
+}
+
+static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32 off,
+ u32 val)
+{
+ irq_reg_writel(val, gc->reg_base + off);
+}
+
+static inline u32 sunxi_sc_nmi_read(struct irq_chip_generic *gc, u32 off)
+{
+ return irq_reg_readl(gc->reg_base + off);
+}
+
+static void sunxi_sc_nmi_handle_irq(unsigned int irq, struct irq_desc *desc)
+{
+ struct irq_domain *domain = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_get_chip(irq);
+ unsigned int virq = irq_find_mapping(domain, 0);
+
+ chained_irq_enter(chip, desc);
+ generic_handle_irq(virq);
+ chained_irq_exit(chip, desc);
+}
+
+static int sunxi_sc_nmi_set_type(struct irq_data *data, unsigned int flow_type)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+ struct irq_chip_type *ct = gc->chip_types;
+ u32 src_type_reg;
+ u32 ctrl_off = ct->regs.type;
+ unsigned int src_type;
+ unsigned int i;
+
+ irq_gc_lock(gc);
+
+ switch (flow_type & IRQF_TRIGGER_MASK) {
+ case IRQ_TYPE_EDGE_FALLING:
+ src_type = SUNXI_SRC_TYPE_EDGE_FALLING;
+ break;
+ case IRQ_TYPE_EDGE_RISING:
+ src_type = SUNXI_SRC_TYPE_EDGE_RISING;
+ break;
+ case IRQ_TYPE_LEVEL_HIGH:
+ src_type = SUNXI_SRC_TYPE_LEVEL_HIGH;
+ break;
+ case IRQ_TYPE_NONE:
+ case IRQ_TYPE_LEVEL_LOW:
+ src_type = SUNXI_SRC_TYPE_LEVEL_LOW;
+ break;
+ default:
+ irq_gc_unlock(gc);
+ pr_err("%s: Cannot assign multiple trigger modes to IRQ %d.\n",
+ __func__, data->irq);
+ return -EBADR;
+ }
+
+ irqd_set_trigger_type(data, flow_type);
+ irq_setup_alt_chip(data, flow_type);
+
+ for (i = 0; i <= gc->num_ct; i++, ct++)
+ if (ct->type & flow_type)
+ ctrl_off = ct->regs.type;
+
+ src_type_reg = sunxi_sc_nmi_read(gc, ctrl_off);
+ src_type_reg &= ~SUNXI_NMI_SRC_TYPE_MASK;
+
[PATCH v4 3/3] ARM: sun7i/sun6i: irqchip: Update the documentation
Added documentation for NMI irqchip.
Signed-off-by: Carlo Caione
---
.../allwinner,sun67i-sc-nmi.txt| 27 ++
1 file changed, 27 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt
b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt
new file mode 100644
index 000..ac31487
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt
@@ -0,0 +1,27 @@
+Allwinner Sunxi NMI Controller
+==
+
+Required properties:
+
+- compatible : should be "allwinner,sun7i-a20-sc-nmi" or
+ "allwinner,sun6i-a31-sc-nmi"
+- reg : Specifies base physical address and size of the registers.
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value shall be 2. The first cell is the IRQ number, the
+ second cell the trigger type.
+- interrupt-parent: Specifies the parent interrupt controller.
+- interrupts: Specifies the list of interrupt lines which are handled by
+ the interrupt controller in the parent controller's notation. This value
+ shall be the NMI.
+
+Example:
+
+sc-nmi-intc@01c00030 {
+ compatible = "allwinner,sun7i-a20-sc-nmi";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x01c00030 0x0c>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 0 4>;
+};
--
1.8.3.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 v8.1 1/6] dt-bindings: sram: describe option to reserve parts of the memory
On Wednesday 26 February 2014, Heiko Stübner wrote: > Some SoCs need parts of their sram for special purposes. So while being part > of the peripheral, it should not be part of the genpool controlling the sram. > > Therefore add the option to define reserved regions as subnodes of the > sram-node similar to defining reserved global memory regions. > > Originally > Suggested-by: Rob Herring > > Using subnodes for reserved regions > Suggested-by: Grant Likely > > Signed-off-by: Heiko Stuebner > Tested-by: Ulrich Prinz Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "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/4] pci: OF: Fix the conversion of IO ranges into IO resources.
On Thu, Feb 27, 2014 at 11:19:51AM -0700, Jason Gunthorpe wrote:
> On Thu, Feb 27, 2014 at 01:06:39PM +, Liviu Dudau wrote:
> > + if (res->flags & IORESOURCE_IO) {
> > + unsigned long port;
> > + port = pci_address_to_pio(range->pci_addr);
>
> This looks very suspicious, pci_addr is not unique across all domains,
> so there is no way to convert from a pci_addr to the virtual IO
> address without knowing the domain number as well.
>
> I would like to see it be:
> port = pci_address_to_pio(range->cpu_addr);
>
> cpu_addr is unique across all domains.
Jason,
First thanks for reviewing the updated series.
We have agreed early on that indeed using range->cpu_addr is the correct aproach
and me taking the lazy shortcut of using range->pci_addr because of the broken
default implementation of pci_address_to_pio is wrong. I will fix this for v3.
The outstanding issue is how to fix pci_address_to_pio() as it will not
for for range->cpu_addr > IO_SPACE_LIMIT (16MB in my case).
Best regards,
Liviu
>
> Looking at the microblaze and PPC versions I think the above version
> is actually correct (assuming io_base_phys is the CPU address of the
> IO window)
>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 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 v12 3/4] PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
Hi, On Thu, Feb 27, 2014 at 11:14:07AM -0700, Loc Ho wrote: > +/* > + * This function is used to configure the PHY to operation as either SATA > Gen1 > + * or Gen2 speed. > + */ > +static void xgene_phy_sata_force_gen(struct xgene_phy_ctx *ctx, > + int lane, int gen) why do you need to *force* the generation ? Is this because of some silicon errata ? It almost seems like this should be done through link negotiation between both link partners. -- balbi signature.asc Description: Digital signature
Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework
Hi, On Thu, Feb 27, 2014 at 11:14:05AM -0700, Loc Ho wrote: > This patch adds function set_speed to the generic PHY framework operation > structure. This function can be called to instruct the PHY underlying layer > at specified lane to configure for specified speed in hertz. why ? looks like clk_set_rate() is your friend here. Can you be more descriptive of the use case ? When will this be used ? -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 1/6] PM / Voltagedomain: Add generic clk notifier handler for regulator based dynamic voltage scaling
Hi, On Wed, Feb 26, 2014 at 08:34:55PM -0600, Nishanth Menon wrote: > On 14:56-20140225, Nishanth Menon wrote: > > On 02/24/2014 11:51 PM, Mike Turquette wrote: > > > Quoting Nishanth Menon (2014-02-18 12:32:18) > [...] > > > I'm not sure about trying to capture the "voltdm" as a core concept. It > > > feels a bit unwieldy to me. > > > > Considering it is a simple collation of regulators and SoC specific > > "magic" which have to be operated in tandem to clock operation, Why > > does it seem unwieldy? Usage of multiple voltage planes in a single > > voltage domain concept does not seem unique to TI processors either: > > For example, imx6q-cpufreq.c uses 3 regulators (arm, pu, soc), > > s5pv210-cpufreq.c uses two regulators (vddarm, vddint), ideally OMAP > > implementation would use two (vdd_mpu, vbb_mpu). > > > > > I have wondered about making an abstract > > > "performance domain" which is the dvfs analogue to generic power > > > domains. This a reasonable split since gpd are good for idle power > > > savings (e.g. clock gate, power gate, sleep state, etc) and "perf > > > domains" would be good for active power savings (dvfs). > > > > > > Having a generic container for performance domains might make a good > > > place to stuff all of this glue logic that we keep running into (e.g. > > > CPU and GPU max frequencies that are related), and it might make another > > > nice knob for the thermal folks to use. > > > > This sounds like one level higher abstraction that we are speaking of > > here? I was'nt intending to solve the bigger picture problem here - > > just an abstraction level that might allow reusablity for multiple > > SoCs. In fact, having an abstraction away for voltage domain(which may > > consist of multiple regulators and any SoC specific magic) purely > > allows us to move towards a direction you mention here. > > > > > > > > For the case of the OMAP voltage domains, it would be a place to stuff > > > all of the VC/VP -> ABB -> Smart Reflex AVS stuff. > > > > > > > Unfortunately, I dont completely comprehend objection we have to this > > approach (other than an higher level abstraction is needed) and if we > > do have an objection, what is the alternate approach should be for > > representing hardware which this series attempts to present. > > I think the following is around the lines of your thought direction - > if Rafael or others have comments on the following approach, it'd be a > good starting point for me to progress. > > -->8-- > From 62e50b9f920495db88e5594aa6bceb52e83a443d Mon Sep 17 00:00:00 2001 > From: Nishanth Menon > Date: Wed, 26 Feb 2014 10:59:59 -0600 > Subject: [PATCH] PM / Runtime: introduce active power management callbacks > for pm_domain > > dev_pm_domain currently handles just device idle power management > using the generic pm_runtime_get|put and related family of functions. > > Logically with appropriate pm_domain hooks this can translate to > hardware specific clock and related operations. Given that pm_domains > may contain this information, this provides an opportunity to extend > current pm_runtime do dynamic power operations as well. > > What this means for drivers is as follows: > > Today, drivers(with some level of complexity) do: > pm_runtime_get_sync(dev); > clk = clk_get(dev, "name"); > old_rate = clk_get_rate(clk); > ... > clk_set_rate(clk, new_rate); > ... > clk_put(clk); > pm_runtime_get_sync(dev); > > Instead, on pm_domains that can handle this as part of > pm_domain->active_ops functions, They can now do the following: > pm_runtime_get_sync(dev); > old_rate = pm_runtime_get_rate(dev); > ... > pm_runtime_set_rate(dev, new_rate); > ... > pm_runtime_put_sync(dev); > > Obviously, this'd work for devices that handle a single main > functional clock, but this could reduce complexity of drivers having > to deal with power management details to have pm_runtime as the main > point of interface. > > CAVEAT: For power domains that are capable of handling multiple > clocks (example on OMAP, where there are the concepts of interface, > functional and optional clocks per block), appropriate handling will > be necessary from pm_domain callbacks. So, the question about which > clock rate is being controlled or returned to is entirely upto the > pm_domain implementation. > > On the otherhand, we can debate about defining and querying ACPI style > "Performance state" instead of frequencies and wrap P-states inside > or the other way around.. but given that majority of drivers using > pm_runtime would rather be interested in frequencies and my naieve > belief that we can index P-states with frequencies, kind of influenced > my choice here of proposing frequencies as base query parameter.. > ofcourse, debate is still open here. > > Yes, we can still debate if providing yet another wrapper on top of > clock APIs makes sense at all as well. > > Nyet-signed-off-by: Nishanth Menon > --- > drivers/base/power/runtime.c | 101 > +
[PATCH 1/1] Memory leak in scripts/dtc/util.c
From: Heinrich Schuchardt
buf was leaked if out of memory
Signed-off-by: Heinrich Schuchardt
---
scripts/dtc/util.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/dtc/util.c b/scripts/dtc/util.c
index 2422c34..a1e2e59 100644
--- a/scripts/dtc/util.c
+++ b/scripts/dtc/util.c
@@ -210,9 +210,11 @@ int utilfdt_read_err(const char *filename, char **buffp)
do {
/* Expand the buffer to hold the next chunk */
if (offset == bufsize) {
+ char *buf_old = buf;
bufsize *= 2;
buf = realloc(buf, bufsize);
if (!buf) {
+ buf = buf_old;
ret = ENOMEM;
break;
}
--
1.7.10.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
Re: [PATCH v2 1/4] pci: OF: Fix the conversion of IO ranges into IO resources.
On Thu, Feb 27, 2014 at 01:06:39PM +, Liviu Dudau wrote:
> + if (res->flags & IORESOURCE_IO) {
> + unsigned long port;
> + port = pci_address_to_pio(range->pci_addr);
This looks very suspicious, pci_addr is not unique across all domains,
so there is no way to convert from a pci_addr to the virtual IO
address without knowing the domain number as well.
I would like to see it be:
port = pci_address_to_pio(range->cpu_addr);
cpu_addr is unique across all domains.
Looking at the microblaze and PPC versions I think the above version
is actually correct (assuming io_base_phys is the CPU address of the
IO window)
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
[PATCH v12 2/4] Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation
This patch adds APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding
documentation.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
.../devicetree/bindings/phy/apm-xgene-phy.txt | 79
1 files changed, 79 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
b/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
new file mode 100644
index 000..5f3a65a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
@@ -0,0 +1,79 @@
+* APM X-Gene 15Gbps Multi-purpose PHY nodes
+
+PHY nodes are defined to describe on-chip 15Gbps Multi-purpose PHY. Each
+PHY (pair of lanes) has its own node.
+
+Required properties:
+- compatible : Shall be "apm,xgene-phy".
+- reg : PHY memory resource is the SDS PHY access resource.
+- #phy-cells : Shall be 1 as it expects one argument for setting
+ the mode of the PHY. Possible values are 0 (SATA),
+ 1 (SGMII), 2 (PCIe), 3 (USB), and 4 (XFI).
+
+Optional properties:
+- status : Shall be "ok" if enabled or "disabled" if disabled.
+ Default is "ok".
+- clocks : Reference to the clock entry.
+- apm,tx-eye-tuning: Manual control to fine tune the capture of the serial
+ bit lines from the automatic calibrated position.
+ Two set of 3-tuple setting for each (up to 3)
+ supported link speed on the host. Range from 0 to
+ 127 in unit of one bit period. Default is 10.
+- apm,tx-eye-direction : Eye tuning manual control direction. 0 means sample
+ data earlier than the nominal sampling point. 1 means
+ sample data later than the nominal sampling point.
+ Two set of 3-tuple setting for each (up to 3)
+ supported link speed on the host. Default is 0.
+- apm,tx-boost-gain: Frequency boost AC (LSB 3-bit) and DC (2-bit)
+ gain control. Two set of 3-tuple setting for each
+ (up to 3) supported link speed on the host. Range is
+ between 0 to 31 in unit of dB. Default is 3.
+- apm,tx-amplitude : Amplitude control. Two set of 3-tuple setting for
+ each (up to 3) supported link speed on the host.
+ Range is between 0 to 199500 in unit of uV.
+ Default is 199500 uV.
+- apm,tx-pre-cursor1 : 1st pre-cursor emphasis taps control. Two set of
+ 3-tuple setting for each (up to 3) supported link
+ speed on the host. Range is 0 to 273000 in unit of
+ uV. Default is 0.
+- apm,tx-pre-cursor2 : 2st pre-cursor emphasis taps control. Two set of
+ 3-tuple setting for each (up to 3) supported link
+ speed on the host. Range is 0 to 127400 in unit uV.
+ Default is 0x0.
+- apm,tx-post-cursor : Post-cursor emphasis taps control. Two set of
+ 3-tuple setting for Gen1, Gen2, and Gen3. Range is
+ between 0 to 0x1f in unit of 18.2mV. Default is 0xf.
+- apm,tx-speed : Tx operating speed. One set of 3-tuple for each
+ supported link speed on the host.
+ 0 = 1-2Gbps
+ 1 = 2-4Gbps (1st tuple default)
+ 2 = 4-8Gbps
+ 3 = 8-15Gbps (2nd tuple default)
+ 4 = 2.5-4Gbps
+ 5 = 4-5Gbps
+ 6 = 5-6Gbps
+ 7 = 6-16Gbps (3rd tuple default)
+
+NOTE: PHY override parameters are board specific setting.
+
+Example:
+ phy1: phy@1f21a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f21a000 0x0 0x100>;
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+
+ phy2: phy@1f22a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f22a000 0x0 0x100>;
+ #phy-cells = <1>;
+ status = "ok";
+ };
+
+ phy3: phy@1f23a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f23a000 0x0 0x100>;
+ #phy-cells = <1>;
+ status = "ok";
+ };
--
1.5.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.o
[PATCH v12 0/4] PHY: Add APM X-Gene SoC 15Gbps Multi-purpose PHY support
This patch adds support for APM X-Gene SoC 15Gbps Multi-purpose PHY. This is the physical layer interface for the corresponding host controller. This driver uses the PHY generic framework. In addition, the PHY generic framework is patched to provide an function to set the speed of the PHY. v12: * Add driver depend on HAS_IOMEM and OF * Fix comment typo in header file phy-xgene. * Change all macro shift value in hex to decimal * Add time out for while loop to function sds_wr and sds_rd * Set proper return value if failed to get IO resource 0 * Move devm_of_phy_provider_register to last operation in probe function * Remove driver registration print statement * Replace module init/exit with module_platform_driver * Change license to GPL v2 v11: * Add comment to function phy_set_speed * Add commit log for documentation patch file * Minor comment update to function xgene_phy_force_lat_summer_cal and xgene_phy_sata_force_gen v10 * Update comment for function xgene_phy_force_lat_summer_cal and xgene_phy_sata_force_gen with function style fully-winged style v9 * Update CMU parameter setting for register 13 * Add required delay when configure CMU PLL, Manual Calibration PLL, and VCO PLL * Add comment for CMU PLL calibration loop delay of 10us * Add required delay for stopping and starting summer calibrations * Update comment for summer and latch calibration delays * Update comment for PHY reset Rx delay and decrease max sleep time from 500 to 150us * Always program the DFE (equalizer) setting to 0x7e00 as with original version * Fix Tx speed selection to always using Gen3 setting when force to an specified generation speed v8 * Update binding documentation * Remove XGENE_PHY_DTS and XGENE_PHY_EXT_DTS defines * Remove support for internal clock * Remove support for external reference CMU * Remove the need for external reference resource DTS entry and its related code v7 * Add/Update PHY CMU/lane parameters and its default values * Rename variable enable_manual_cal to preA3Chip * Remove function phy_rd, phy_wr, and phy_wr_flush * Change function cmu_wr, cmu_rd, cmu_toggle1to0, cmu_clrbits, cmu_setbits, serdes_wr, serdes_rd, serdes_clrbits, and serdes_setbits to take context instead void * * Remove function serdes_toggle1to0 * Decrease the polling time from 10ms to 1ms on CMU calibration complete detection * Move all SATA specify code in function xgene_phy_hw_initialize into function xgene_phy_hw_init_sata * Add usleep_range after starting summer/latch calibrations * Add usleep_range between receiver reset (function xgene_phy_reset_rxd) * Save and restore PHY register 31 instead writing 0 in function xgene_phy_gen_avg_val * Update function xgene_phy_sata_force_gen programming sequences * Add support to reset the receiver lane in function xgene_phy_set_speed if speed is 0 * Update PHY parameters in DTS per controller * Some minor code clean up v6 * Move PHY document to Documentation/devicetree/binding/phy * Remove _ADDR from all register defines * Update clock-names property for sataphy1clk, sataphy2clk, and sataphy3clk v5 * Update DTS binding documentation * Remove direct clock access and use clock interface instead * Change override parameters to decimal instead hex values * Change apm,tx-amplitude, apm,tx-pre-cursor1, apm,tx-pre-cursor2, apm,tx-post-cursor to be unit of uV v4 * Update documentation with 'apm,' instead 'apm-' * Change DTS override parameter to have 'apm,' * Add select GENERIC_PHY to Kconfig PHY_XGENE * Make override parameters to be pair of three values instead one * Some minor comment and indentation changes * Remove error register addition offset * Add ULL to constants * Use module_init instead subsys_initcall * Make DTS node based on first register address * Update override setting values v3 * Major re-write of the code based on various review comments * Support external clock only at the moment * Support SATA mode only at the moment * No UEFI support at the moment v2 * Remove port knowledge from functions * Make all functions static * Remove ID completely * Make resource requirement based on compatible type * Rename override PHY parameters with more descriptive name * Add override PHY parameter for per controller, per port, and per speed * Patch the generic PHY frame to expose set_speed operation v1 * Initial version Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- Loc Ho (4): PHY: Add function set_speed to generic PHY framework Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries .../devicetree/bindings/phy/apm-xgene-phy.txt | 79 + arch/arm64/boot/dts/apm-storm.dtsi | 75 + drivers/phy/Kconfig|7 + drivers/phy/Makefile |2 + drivers/phy/phy-core.c
[PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework
This patch adds function set_speed to the generic PHY framework operation
structure. This function can be called to instruct the PHY underlying layer
at specified lane to configure for specified speed in hertz.
Signed-off-by: Loc Ho
---
drivers/phy/phy-core.c | 30 ++
include/linux/phy/phy.h |8
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 645c867..5451b6d 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -258,6 +258,36 @@ int phy_power_off(struct phy *phy)
EXPORT_SYMBOL_GPL(phy_power_off);
/**
+ * phy_set_speed - set an specified lane at an specified speed
+ * @phy: phy instance to be set
+ * @lane: zero-based lane index
+ * @speed: operating speed in hz
+ *
+ * Returns 0 if successful, -ENOTSUPP if not supported,
+ * -EINVAL if parameter out of range.
+ */
+int phy_set_speed(struct phy *phy, int lane, u64 speed)
+{
+int ret = -ENOTSUPP;
+
+mutex_lock(&phy->mutex);
+if (phy->ops->set_speed) {
+ret = phy->ops->set_speed(phy, lane, speed);
+if (ret < 0) {
+dev_err(&phy->dev, "phy set speed failed --> %d\n",
+ret);
+goto out;
+}
+}
+
+out:
+mutex_unlock(&phy->mutex);
+
+return ret;
+}
+EXPORT_SYMBOL_GPL(phy_set_speed);
+
+/**
* of_phy_get() - lookup and obtain a reference to a phy by phandle
* @dev: device that requests this phy
* @index: the index of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e273e5a..4eb589c 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -27,6 +27,7 @@ struct phy;
* @exit: operation to be performed while exiting
* @power_on: powering on the phy
* @power_off: powering off the phy
+ * @set_speed: set operation speed in hz
* @owner: the module owner containing the ops
*/
struct phy_ops {
@@ -34,6 +35,7 @@ struct phy_ops {
int (*exit)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
+ int (*set_speed)(struct phy *phy, int lane, u64 speed);
struct module *owner;
};
@@ -145,6 +147,7 @@ static inline void phy_set_bus_width(struct phy *phy, int
bus_width)
{
phy->attrs.bus_width = bus_width;
}
+int phy_set_speed(struct phy *phy, int lane, u64 speed);
struct phy *phy_get(struct device *dev, const char *string);
struct phy *devm_phy_get(struct device *dev, const char *string);
void phy_put(struct phy *phy);
@@ -227,6 +230,11 @@ static inline void phy_set_bus_width(struct phy *phy, int
bus_width)
return;
}
+static inline int phy_set_speed(struct phy *phy, int lane, u64 speed)
+{
+ return -ENOSYS;
+}
+
static inline struct phy *phy_get(struct device *dev, const char *string)
{
return ERR_PTR(-ENOSYS);
--
1.5.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 v12 4/4] arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries
This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose
PHY driver. The PHY for SATA controller 2 and 3 are enabled by default.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
arch/arm64/boot/dts/apm-storm.dtsi | 75
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index d37d736..c78ddcf 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -176,6 +176,51 @@
reg-names = "csr-reg";
clock-output-names = "eth8clk";
};
+
+ sataphy1clk: sataphy1clk@1f21c000 {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ clock-names = "socplldiv2";
+ reg = <0x0 0x1f21c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "sataphy1clk";
+ status = "disabled";
+ csr-offset = <0x4>;
+ csr-mask = <0x00>;
+ enable-offset = <0x0>;
+ enable-mask = <0x06>;
+ };
+
+ sataphy2clk: sataphy1clk@1f22c000 {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ clock-names = "socplldiv2";
+ reg = <0x0 0x1f22c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "sataphy2clk";
+ status = "ok";
+ csr-offset = <0x4>;
+ csr-mask = <0x3a>;
+ enable-offset = <0x0>;
+ enable-mask = <0x06>;
+ };
+
+ sataphy3clk: sataphy1clk@1f23c000 {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ clock-names = "socplldiv2";
+ reg = <0x0 0x1f23c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "sataphy3clk";
+ status = "ok";
+ csr-offset = <0x4>;
+ csr-mask = <0x3a>;
+ enable-offset = <0x0>;
+ enable-mask = <0x06>;
+ };
};
serial0: serial@1c02 {
@@ -187,5 +232,35 @@
interrupt-parent = <&gic>;
interrupts = <0x0 0x4c 0x4>;
};
+
+ phy1: phy@1f21a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f21a000 0x0 0x100>;
+ #phy-cells = <1>;
+ clocks = <&sataphy1clk 0>;
+ status = "disabled";
+ apm,tx-boost-gain = <30 30 30 30 30 30>;
+ apm,tx-eye-tuning = <2 10 10 2 10 10>;
+ };
+
+ phy2: phy@1f22a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f22a000 0x0 0x100>;
+ #phy-cells = <1>;
+ clocks = <&sataphy2clk 0>;
+ status = "ok";
+ apm,tx-boost-gain = <30 30 30 30 30 30>;
+ apm,tx-eye-tuning = <1 10 10 2 10 10>;
+ };
+
+ phy3: phy@1f23a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f23a000 0x0 0x100>;
+ #phy-cells = <1>;
+ clocks = <&sataphy3clk 0>;
+ status = "ok";
+ apm,tx-boost-gain = <31 31 31 31 31 31>;
+ apm,tx-eye-tuning = <2 10 10 2 10 10>;
+ };
};
};
--
1.5.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 v3 1/3] dma: Support multiple interleaved frames with non-contiguous memory
On Wed, Feb 26, 2014 at 8:32 PM, Jassi Brar wrote: > On 26 February 2014 23:21, Srikanth Thokala wrote: >> On Mon, Feb 24, 2014 at 7:39 AM, Jassi Brar >> wrote: >>> On 21 February 2014 23:37, Srikanth Thokala wrote: On Thu, Feb 20, 2014 at 3:23 PM, Jassi Brar wrote: > On 20 February 2014 14:54, Srikanth Thokala wrote: >> On Wed, Feb 19, 2014 at 12:33 AM, Jassi Brar >> wrote: >>> On 18 February 2014 23:16, Srikanth Thokala wrote: On Tue, Feb 18, 2014 at 10:20 PM, Jassi Brar wrote: > On 18 February 2014 16:58, Srikanth Thokala > wrote: >> On Mon, Feb 17, 2014 at 3:27 PM, Jassi Brar >> wrote: >>> On 15 February 2014 17:30, Srikanth Thokala >>> wrote: The current implementation of interleaved DMA API support multiple frames only when the memory is contiguous by incrementing src_start/ dst_start members of interleaved template. But, when the memory is non-contiguous it will restrict slave device to not submit multiple frames in a batch. This patch handles this issue by allowing the slave device to send array of interleaved dma templates each having a different memory location. >>> How fragmented could be memory in your case? Is it inefficient to >>> submit separate transfers for each segment/frame? >>> It will help if you could give a typical example (chunk size and gap >>> in bytes) of what you worry about. >> >> With scatter-gather engine feature in the hardware, submitting >> separate >> transfers for each frame look inefficient. As an example, our DMA >> engine >> supports up to 16 video frames, with each frame (a typical video >> frame >> size) being contiguous in memory but frames are scattered into >> different >> locations. We could not definitely submit frame by frame as it would >> be >> software overhead (HW interrupting for each frame) resulting in video >> lags. >> > IIUIC, it is 30fps and one dma interrupt per frame ... it doesn't seem > inefficient at all. Even poor-latency audio would generate a higher > interrupt-rate. So the "inefficiency concern" doesn't seem valid to > me. > > Not to mean we shouldn't strive to reduce the interrupt-rate further. > Another option is to emulate the ring-buffer scheme of ALSA which > should be possible since for a session of video playback the frame > buffers' locations wouldn't change. > > Yet another option is to use the full potential of the > interleaved-xfer api as such. It seems you confuse a 'video frame' > with the interleaved-xfer api's 'frame'. They are different. > > Assuming your one video frame is F bytes long and Gk is the gap in > bytes between end of frame [k] and start of frame [k+1] and Gi != Gj > for i!=j > In the context of interleaved-xfer api, you have just 1 Frame of 16 > chunks. Each chunk is Fbytes and the inter-chunk-gap(ICG) is Gk where > 0<=k<15 > So for your use-case . > dma_interleaved_template.numf = 1 /* just 1 frame */ > dma_interleaved_template.frame_size = 16 /* containing 16 chunks */ >.. //other parameters > > You have 3 options to choose from and all should work just as fine. > Otherwise please state your problem in real numbers (video-frames' > size, count & gap in bytes). Initially I interpreted interleaved template the same. But, Lars corrected me in the subsequent discussion and let me put it here briefly, In the interleaved template, each frame represents a line of size denoted by chunk.size and the stride by icg. 'numf' represent number of frames i.e. number of lines. In video frame context, chunk.size -> hsize chunk.icg -> stride numf -> vsize and frame_size is always 1 as it will have only one chunk in a line. >>> But you said in your last post >>> "with each frame (a typical video frame size) being contiguous in >>> memory" >>> ... which is not true from what you write above. Anyways, my first 2 >>> suggestions still hold. >> >> Yes, each video frame is contiguous and they can be scattered. >> > I assume by contiguous frame you mean as in framebuffer? Which is an > array of bytes. > If yes, then you should do as I suggest first, frame_size=16 and numf=1. I think am confusing you. I would like to explain with an example. Lets say each video frame is 4k size starti
Re: [PATCH 2/4] net: rfkill: gpio: remove gpio names
On 02/27/2014 10:38 AM, Gross, Mark wrote:
> Please know that no one should not consider me an authority on ACPI at this
> time. But, I have some comments / context / thoughts below.
>
> Also I apologize in advance for any email formatting issues caused by
> replying to this via my work exchange account / outlook client. Folks can
> use mgr...@linux.intel.com to avoid outlook-isms from me in the future.
>
>> -Original Message-
>> From: Linus Walleij [mailto:linus.wall...@linaro.org]
>> Sent: Tuesday, February 25, 2014 1:14 AM
>> To: Stephen Warren; Alexandre Courbot; Grant Likely;
>> devicetree@vger.kernel.org
>> Cc: Chen-Yu Tsai; Heikki Krogerus; Johannes Berg; David S. Miller; Rhyland
>> Klein; linux-wireless; netdev; linux-kernel; Arnd Bergmann; Gross, Mark
>> Subject: Re: [PATCH 2/4] net: rfkill: gpio: remove gpio names
>>
>> On Fri, Feb 21, 2014 at 6:35 AM, Stephen Warren
>> wrote:
>>> On 02/20/2014 06:55 PM, Chen-Yu Tsai wrote:
>>
That's correct. However using con_id to pass this results in
different behavior across DT and ACPI. A better way is to export the
labeling function so consumers can set meaningful labels themselves.
>>>
>>> But this code is the consumer of those GPIOs. IF the parameter to
>>> devm_gpiod_get_index() isn't intended to be used, why does it exist?
>>
>> Kerneldoc says:
>>
>> /**
>> * gpiod_get_index - obtain a GPIO from a multi-index GPIO function
>> * @dev:GPIO consumer, can be NULL for system-global GPIOs
>> * @con_id: function within the GPIO consumer
>> * @idx:index of the GPIO to obtain in the consumer
>> *
>>
>> Basically it is just exposing the fact that of_find_gpio() and
>> acpi_find_gpio() both take a con_id as argument.
>>
>> If we drill into this, we find that it is used to conjure the arbitrary
>> string
>> before the gpios in the DT case, like:
>>
>> foo-gpios = <...>;
>>
>> As in tegra30-beaver.dts...
>>
>> sdhci@7800 {
>> status = "okay";
>> cd-gpios = <&gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
>> wp-gpios = <&gpio TEGRA_GPIO(T, 3) GPIO_ACTIVE_HIGH>;
>> power-gpios = <&gpio TEGRA_GPIO(D, 7) GPIO_ACTIVE_HIGH>;
>> bus-width = <4>;
>> };
>>
>> Instead of passing the GPIOs as index 0,1,2 they are named and I do admit
>> this has a nice "things are under control" aspect to it.
>
> [Gross, Mark] FWIW I don't think this is as "under control" as you do. Those
> names in the above sdhci example are derived from a specific SDHCI
tegra spec
> sheet or schematic. Those names likely come from the data sheet for
> the controller.
The names of the properties are fixed and defined by the DT binding for
the Tegra SDHCI controller, or even the core SDHCI bindings. Hence, they
will be the same in every DT file that uses that Tegra SDHCI compatible
value (the compatible property isn't show above, because the above
fragment is a board.dts file, and the compatible value gets inherited
from the soc.dtsi file). There won't be any variation at all,
irrespective of what signal names exist in a particular board schematic.
If there were ever an (upstream?) ACPI "binding"(?) for the Tegra SDHCI
controller, I would hope it would use the exact same names for the GPIO
signals.
--
To unsubscribe from this list: send the line "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/4] net: rfkill: gpio: remove gpio names
Please know that no one should not consider me an authority on ACPI at this
time. But, I have some comments / context / thoughts below.
Also I apologize in advance for any email formatting issues caused by replying
to this via my work exchange account / outlook client. Folks can use
mgr...@linux.intel.com to avoid outlook-isms from me in the future.
> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: Tuesday, February 25, 2014 1:14 AM
> To: Stephen Warren; Alexandre Courbot; Grant Likely;
> devicetree@vger.kernel.org
> Cc: Chen-Yu Tsai; Heikki Krogerus; Johannes Berg; David S. Miller; Rhyland
> Klein; linux-wireless; netdev; linux-kernel; Arnd Bergmann; Gross, Mark
> Subject: Re: [PATCH 2/4] net: rfkill: gpio: remove gpio names
>
> On Fri, Feb 21, 2014 at 6:35 AM, Stephen Warren
> wrote:
> > On 02/20/2014 06:55 PM, Chen-Yu Tsai wrote:
>
> >> That's correct. However using con_id to pass this results in
> >> different behavior across DT and ACPI. A better way is to export the
> >> labeling function so consumers can set meaningful labels themselves.
> >
> > But this code is the consumer of those GPIOs. IF the parameter to
> > devm_gpiod_get_index() isn't intended to be used, why does it exist?
>
> Kerneldoc says:
>
> /**
> * gpiod_get_index - obtain a GPIO from a multi-index GPIO function
> * @dev:GPIO consumer, can be NULL for system-global GPIOs
> * @con_id: function within the GPIO consumer
> * @idx:index of the GPIO to obtain in the consumer
> *
>
> Basically it is just exposing the fact that of_find_gpio() and
> acpi_find_gpio() both take a con_id as argument.
>
> If we drill into this, we find that it is used to conjure the arbitrary string
> before the gpios in the DT case, like:
>
> foo-gpios = <...>;
>
> As in tegra30-beaver.dts...
>
> sdhci@7800 {
> status = "okay";
> cd-gpios = <&gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
> wp-gpios = <&gpio TEGRA_GPIO(T, 3) GPIO_ACTIVE_HIGH>;
> power-gpios = <&gpio TEGRA_GPIO(D, 7) GPIO_ACTIVE_HIGH>;
> bus-width = <4>;
> };
>
> Instead of passing the GPIOs as index 0,1,2 they are named and I do admit
> this has a nice "things are under control" aspect to it.
[Gross, Mark] FWIW I don't think this is as "under control" as you do. Those
names in the above sdhci example are derived from a specific SDHCI tegra spec
sheet or schematic. Those names likely come from the data sheet for the
controller. I would like SDHCI kernel drivers to work pretty much the same for
all compatible controllers. The set of compatible controllers have spec sheets
that use different naming conventions for their pins and thus a name space
pollution of the SDHCI enumeration ABI will be a problem.
>
> In the ACPI case the con_id is not used for anything.
>
> So it is basically there to satisfy the habit in some device tree bindings to
> name gpio arrays instead of just passing gpios = <...>; (The latter should be
> encouraged going forward.)
[Gross, Mark] This is in fact just an idiom of the ACPI ABI inherited from
writing linux drivers that work on systems with BIOS/FW developed for
MS-Windows. For the devices I work on we have a number of driver teams filing
bugs against the BIOS/FW to add named GPIO objects to device name spaces such
that they can directly query for the GPIO their driver needs and avoid assuming
the 3rd GPIO is the special one they need for whatever...
So if you have the luxury of being able to influence (file bugs against or
write) the platform enumeration ABI then with ACPI you can have a named gpio
today. Note: there is an expectation that the _PRP feature to go into the next
version of ACPI and that should enable a trivial 1-1 mapping (when _prp is used
by the ACPI platform) between the different platform enumeration API's (DT and
ACPI).
Still, from a platform enumeration ABI point of view I see the arbitrariness of
indexes not much worse than the arbitrary naming of pins off of spec sheets or
schematics. Given that the authors of those specs/layouts come up with a new
naming schemes every time they log into their workstations (especially for the
schematics). I do admit names are a little better but still have the scaling
issue WRT namespaces and arbitrary naming by HW engineers over time.
>
> As DT is ABI we need to keep this forever, and driver may need to look for
> foo-gpios=<> and gpios=<> alike for backward compatibility if we'd change it,
> sweet isn't it? :-)
>
> I don't quite like this, as it is adding stupid nonsens arguments for ACPI
> GPIO
> producers (which only take an index AFAICT), but it is a first sacrifice on
> the
> altar of trying to mask the differences between DT and ACPI probe paths
> about which I have mixed feelings.
[Gross, Mark] I don't have mixed feelings. I want to see converged probe paths
that can handle both ACPI and DT platform ABI's seamlessly so
Re: [PATCH v2] dt: platform driver: Fill the resources before probe and defer if needed
Hi Grant,
2014-02-21 17:22 GMT+01:00 Jean-Jacques Hiblot :
> Hi Grygorii,
>
> 2014-02-21 16:37 GMT+01:00 Strashko, Grygorii :
>> Hi Jean-Jacques,
>>
>> Sorry for top posting.
>>
>> As I know, there have been several attempts to solve the same problem
>> already:)
>> [1] https://lkml.org/lkml/2013/9/18/216
>> [2] https://lkml.org/lkml/2013/11/22/520
>> [3] https://lkml.org/lkml/2014/1/8/240
>>
>> There are some questions related to your approach:
>> 1) How to distinguish between cases "IRQ domain not ready" and "wrong IRQ
>> data in DT" or other IRQ parsing errors?
>> Otherwise, Driver's probe will be deffered wrongly and forever,
>> Thierry Reding has tried to solve this in [1].
>
> This approach doesn't really care about the cause of the problem. I'm
> of the opinion that never-ending deferred probing is not a big issue,
> being not triggered so often after start-up (only when a new device is
> probed). But if we need to make it right, then we would have to change
> a bit the API of irq_create_of_mapping() and irq_of_parse_and_map()
> (or maybe duplicate this one to keep the patch small) to return a real
> error code instead a simple 0. Then would should be able to
> distinguish the different error causes.
What do you think of the 2nd version of the patch? Is it all right to
allways return EPROBE_DEFER or should we try to discriminate the error
cause?
Jean-Jacques
>
>>
>> 2) How will be handled driver reloading situation?
>> The worst case (sparse IRQ enabled):
>> - remove driver A
>> - remove driver B (irq-controller)
>> - load driver B <--- different set of Linux IRQ numbers can be assigned
>> - load driver A <--- oops. IRQ resources table contains invalid data
>>
>
> It's not handled in the current implementation. But if all interrupts
> entries are re-parsed (see my comment for Grant), it should be all
> right.
> Another problem would appear if the DT is dynamically updated and the
> number of resource is changed. In the 1st version of the patch, this
> was handled but it made the function more expensive.
>
> Jean-Jacques
>>
>>
>> Best regards,
>> Grygorii Strashko
>>
>> =
>>
>> The goal of this patch is to allow drivers to be probed even if at the time
>> of
>> the DT parsing some of their ressources are not available yet.
>>
>> In the current situation, the resource of a platform device are filled from
>> the
>> DT at the time the device is created (of_device_alloc()). The drawbackof this
>> is that a device sitting close to the top of the DT (ahb for example) but
>> depending on ressources that are initialized later (IRQ domain dynamically
>> created for example) will fail to probe because the ressources don't exist
>> at this time.
>>
>> This patch fills the resource structure only before the device is probed and
>> will defer the probe if the resource are not available yet.
>>
>> Signed-off-by: Jean-Jacques Hiblot
>> Reviewed-by: Gregory CLEMENT
>> ---
>>
>> Hi Grant,
>>
>> I reworked the patch as you proposed. To keep the overhead minimum, nirq and
>> nreg are computed only the first time.
>> In this implementation, only the missing IRQ ressources are re-tried for. It
>> could
>> easily be changed to re-parse all the IRQs though (replace if (!res->flags)
>> with if ((!res->flags) || (res->flags & IORESOURCE_IRQ)).
>>
>> drivers/base/platform.c | 5 +++
>> drivers/of/platform.c | 100
>> +---
>> include/linux/of_platform.h | 10 +
>> 3 files changed, 90 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
>> index bc78848..cee9b8d 100644
>> --- a/drivers/base/platform.c
>> +++ b/drivers/base/platform.c
>> @@ -481,6 +481,10 @@ static int platform_drv_probe(struct device *_dev)
>> struct platform_device *dev = to_platform_device(_dev);
>> int ret;
>>
>> + ret = of_platform_device_prepare(dev);
>> + if (ret)
>> + goto error;
>> +
>> if (ACPI_HANDLE(_dev))
>> acpi_dev_pm_attach(_dev, true);
>>
>> @@ -488,6 +492,7 @@ static int platform_drv_probe(struct device *_dev)
>> if (ret && ACPI_HANDLE(_dev))
>> acpi_dev_pm_detach(_dev, true);
>>
>> +error:
>> if (drv->prevent_deferred_probe && ret == -EPROBE_DEFER) {
>> dev_warn(_dev, "probe deferral not supported\n");
>> ret = -ENXIO;
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index 404d1da..a4e2602 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -141,36 +141,11 @@ struct platform_device *of_device_alloc(struct
>> device_node *np,
>> struct device *parent)
>> {
>> struct platform_device *dev;
>> - int rc, i, num_reg = 0, num_irq;
>> - struct resource *res, temp_res;
>>
>> dev = platform_device_alloc("", -1);
>> if (!dev)
>> return NULL;
[PATCH v5 4/7] of: Reduce indentation in of_graph_get_next_endpoint
A 'return endpoint;' at the end of the (!prev) case allows to
reduce the indentation level of the (prev) case.
Signed-off-by: Philipp Zabel
---
drivers/of/base.c | 42 ++
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 6e650cf..8ecca7a 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2026,32 +2026,34 @@ struct device_node *of_graph_get_next_endpoint(const
struct device_node *parent,
pr_err("%s(): no endpoint nodes specified for %s\n",
__func__, parent->full_name);
of_node_put(node);
- } else {
- port = of_get_parent(prev);
- if (WARN_ONCE(!port, "%s(): endpoint has no parent node\n",
- __func__))
- return NULL;
- /* Avoid dropping prev node refcount to 0. */
- of_node_get(prev);
- endpoint = of_get_next_child(port, prev);
- if (endpoint) {
- of_node_put(port);
- return endpoint;
- }
+ return endpoint;
+ }
- /* No more endpoints under this port, try the next one. */
- do {
- port = of_get_next_child(parent, port);
- if (!port)
- return NULL;
- } while (of_node_cmp(port->name, "port"));
+ port = of_get_parent(prev);
+ if (WARN_ONCE(!port, "%s(): endpoint has no parent node\n",
+ __func__))
+ return NULL;
- /* Pick up the first endpoint in this port. */
- endpoint = of_get_next_child(port, NULL);
+ /* Avoid dropping prev node refcount to 0. */
+ of_node_get(prev);
+ endpoint = of_get_next_child(port, prev);
+ if (endpoint) {
of_node_put(port);
+ return endpoint;
}
+ /* No more endpoints under this port, try the next one. */
+ do {
+ port = of_get_next_child(parent, port);
+ if (!port)
+ return NULL;
+ } while (of_node_cmp(port->name, "port"));
+
+ /* Pick up the first endpoint in this port. */
+ endpoint = of_get_next_child(port, NULL);
+ of_node_put(port);
+
return endpoint;
}
EXPORT_SYMBOL(of_graph_get_next_endpoint);
--
1.8.5.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
[PATCH v5 3/7] of: Warn if of_graph_get_next_endpoint is called with the root node
If of_graph_get_next_endpoint is given a parentless node instead of an
endpoint node, it is clearly a bug.
Signed-off-by: Philipp Zabel
---
drivers/of/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index b2f223f..6e650cf 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2028,8 +2028,8 @@ struct device_node *of_graph_get_next_endpoint(const
struct device_node *parent,
of_node_put(node);
} else {
port = of_get_parent(prev);
- if (!port)
- /* Hm, has someone given us the root node ?... */
+ if (WARN_ONCE(!port, "%s(): endpoint has no parent node\n",
+ __func__))
return NULL;
/* Avoid dropping prev node refcount to 0. */
--
1.8.5.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
[PATCH v5 5/7] [media] of: move common endpoint parsing to drivers/of
This patch adds a new struct of_endpoint which is then embedded in struct
v4l2_of_endpoint and contains the endpoint properties that are not V4L2
(or even media) specific: the port number, endpoint id, local device tree
node and remote endpoint phandle. of_graph_parse_endpoint parses those
properties and is used by v4l2_of_parse_endpoint, which just adds the
V4L2 MBUS information to the containing v4l2_of_endpoint structure.
Signed-off-by: Philipp Zabel
---
Changes since v4:
- Fixed users of struct v4l2_of_endpoint
- Removed left-over #include from v4l2-of.h
---
drivers/media/platform/exynos4-is/media-dev.c | 10 -
drivers/media/platform/exynos4-is/mipi-csis.c | 2 +-
drivers/media/v4l2-core/v4l2-of.c | 16 +++---
drivers/of/base.c | 31 +++
include/linux/of_graph.h | 20 +
include/media/v4l2-of.h | 8 ++-
6 files changed, 62 insertions(+), 25 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index d0f82da..04d6ecd 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -469,10 +469,10 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
return 0;
v4l2_of_parse_endpoint(ep, &endpoint);
- if (WARN_ON(endpoint.port == 0) || index >= FIMC_MAX_SENSORS)
+ if (WARN_ON(endpoint.base.port == 0) || index >= FIMC_MAX_SENSORS)
return -EINVAL;
- pd->mux_id = (endpoint.port - 1) & 0x1;
+ pd->mux_id = (endpoint.base.port - 1) & 0x1;
rem = of_graph_get_remote_port_parent(ep);
of_node_put(ep);
@@ -494,13 +494,13 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
return -EINVAL;
}
- if (fimc_input_is_parallel(endpoint.port)) {
+ if (fimc_input_is_parallel(endpoint.base.port)) {
if (endpoint.bus_type == V4L2_MBUS_PARALLEL)
pd->sensor_bus_type = FIMC_BUS_TYPE_ITU_601;
else
pd->sensor_bus_type = FIMC_BUS_TYPE_ITU_656;
pd->flags = endpoint.bus.parallel.flags;
- } else if (fimc_input_is_mipi_csi(endpoint.port)) {
+ } else if (fimc_input_is_mipi_csi(endpoint.base.port)) {
/*
* MIPI CSI-2: only input mux selection and
* the sensor's clock frequency is needed.
@@ -508,7 +508,7 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
pd->sensor_bus_type = FIMC_BUS_TYPE_MIPI_CSI2;
} else {
v4l2_err(&fmd->v4l2_dev, "Wrong port id (%u) at node %s\n",
-endpoint.port, rem->full_name);
+endpoint.base.port, rem->full_name);
}
/*
* For FIMC-IS handled sensors, that are placed under i2c-isp device
diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c
b/drivers/media/platform/exynos4-is/mipi-csis.c
index fd1ae65..3678ba5 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -772,7 +772,7 @@ static int s5pcsis_parse_dt(struct platform_device *pdev,
/* Get port node and validate MIPI-CSI channel id. */
v4l2_of_parse_endpoint(node, &endpoint);
- state->index = endpoint.port - FIMC_INPUT_MIPI_CSI2_0;
+ state->index = endpoint.base.port - FIMC_INPUT_MIPI_CSI2_0;
if (state->index < 0 || state->index >= CSIS_MAX_ENTITIES)
return -ENXIO;
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index f919db3..b4ed9a9 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -127,17 +127,9 @@ static void v4l2_of_parse_parallel_bus(const struct
device_node *node,
int v4l2_of_parse_endpoint(const struct device_node *node,
struct v4l2_of_endpoint *endpoint)
{
- struct device_node *port_node = of_get_parent(node);
-
- memset(endpoint, 0, offsetof(struct v4l2_of_endpoint, head));
-
- endpoint->local_node = node;
- /*
-* It doesn't matter whether the two calls below succeed.
-* If they don't then the default value 0 is used.
-*/
- of_property_read_u32(port_node, "reg", &endpoint->port);
- of_property_read_u32(node, "reg", &endpoint->id);
+ of_graph_parse_endpoint(node, &endpoint->base);
+ endpoint->bus_type = 0;
+ memset(&endpoint->bus, 0, sizeof(endpoint->bus));
v4l2_of_parse_csi_bus(node, endpoint);
/*
@@ -147,8 +139,6 @@ int v4l2_of_parse_endpoint(const struct device_node *node,
if (endpoint->bus.mipi_csi2.flags == 0)
v4l2_of_parse_parallel_bus(node, endpoint);
- of_node_put(port_node);
-
return 0;
}
EXPORT_SYMBOL(v4l2_of_parse_endpo
[PATCH v5 1/7] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of
This patch moves the parsing helpers used to parse connected graphs
in the device tree, like the video interface bindings documented in
Documentation/devicetree/bindings/media/video-interfaces.txt, from
drivers/media/v4l2-core/v4l2-of.c into drivers/of/base.c.
This allows to reuse the same parser code from outside the V4L2
framework, most importantly from display drivers.
The functions v4l2_of_get_next_endpoint, v4l2_of_get_remote_port,
and v4l2_of_get_remote_port_parent are moved. They are renamed to
of_graph_get_next_endpoint, of_graph_get_remote_port, and
of_graph_get_remote_port_parent, respectively.
Since there are not that many current users yet, switch all of
them to the new functions right away.
Signed-off-by: Philipp Zabel
---
Changes since v4:
- Moved into drivers/of/base.c instead of creating of_graph.c
---
drivers/media/i2c/adv7343.c | 4 +-
drivers/media/i2c/mt9p031.c | 4 +-
drivers/media/i2c/s5k5baf.c | 3 +-
drivers/media/i2c/tvp514x.c | 3 +-
drivers/media/i2c/tvp7002.c | 3 +-
drivers/media/platform/exynos4-is/fimc-is.c | 6 +-
drivers/media/platform/exynos4-is/media-dev.c | 3 +-
drivers/media/platform/exynos4-is/mipi-csis.c | 3 +-
drivers/media/v4l2-core/v4l2-of.c | 117 -
drivers/of/base.c | 118 ++
include/linux/of_graph.h | 46 ++
include/media/v4l2-of.h | 25 +-
12 files changed, 182 insertions(+), 153 deletions(-)
create mode 100644 include/linux/of_graph.h
diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
index d4e15a6..9d38f7b 100644
--- a/drivers/media/i2c/adv7343.c
+++ b/drivers/media/i2c/adv7343.c
@@ -26,12 +26,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
-#include
#include "adv7343_regs.h"
@@ -410,7 +410,7 @@ adv7343_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- np = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
+ np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
if (!np)
return NULL;
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index e5ddf47..192c4aa 100644
--- a/drivers/media/i2c/mt9p031.c
+++ b/drivers/media/i2c/mt9p031.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,7 +30,6 @@
#include
#include
#include
-#include
#include
#include "aptina-pll.h"
@@ -943,7 +943,7 @@ mt9p031_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- np = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
+ np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
if (!np)
return NULL;
diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
index 77e10e0..2d768ef 100644
--- a/drivers/media/i2c/s5k5baf.c
+++ b/drivers/media/i2c/s5k5baf.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1855,7 +1856,7 @@ static int s5k5baf_parse_device_node(struct s5k5baf
*state, struct device *dev)
if (ret < 0)
return ret;
- node_ep = v4l2_of_get_next_endpoint(node, NULL);
+ node_ep = of_graph_get_next_endpoint(node, NULL);
if (!node_ep) {
dev_err(dev, "no endpoint defined at node %s\n",
node->full_name);
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index 83d85df..ca00117 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1068,7 +1069,7 @@ tvp514x_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- endpoint = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
+ endpoint = of_graph_get_next_endpoint(client->dev.of_node, NULL);
if (!endpoint)
return NULL;
diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
index 912e1cc..c4e1e2c 100644
--- a/drivers/media/i2c/tvp7002.c
+++ b/drivers/media/i2c/tvp7002.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -957,7 +958,7 @@ tvp7002_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- endpoint = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
+ endpoint = of_graph_get_next_endpoint(client->dev.of_node, NULL);
if (!endpoint)
return NULL
[PATCH v5 0/7] Move device tree graph parsing helpers to drivers/of
Hi, this version of the OF graph helper move series addresses a few of Grant's and Tomi's comments. Changes since v4: - Moved graph helpers into drivers/of/base.c - Fixed endpoint parsing patch to update users - Improved documentation, emphasizing features that differentiate the graph bindings from simple phandle graphs. Made it clear that this is not necessarily specific to data connections - Added cleanups to of_graph_get_next_endpoint routine - Added simplified binding for single port devices regards Philipp Philipp Zabel (7): [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of Documentation: of: Document graph bindings of: Warn if of_graph_get_next_endpoint is called with the root node of: Reduce indentation in of_graph_get_next_endpoint [media] of: move common endpoint parsing to drivers/of of: Implement simplified graph binding for single port devices of: Document simplified graph binding for single port devices Documentation/devicetree/bindings/graph.txt | 137 + drivers/media/i2c/adv7343.c | 4 +- drivers/media/i2c/mt9p031.c | 4 +- drivers/media/i2c/s5k5baf.c | 3 +- drivers/media/i2c/tvp514x.c | 3 +- drivers/media/i2c/tvp7002.c | 3 +- drivers/media/platform/exynos4-is/fimc-is.c | 6 +- drivers/media/platform/exynos4-is/media-dev.c | 13 +- drivers/media/platform/exynos4-is/mipi-csis.c | 5 +- drivers/media/v4l2-core/v4l2-of.c | 133 + drivers/of/base.c | 165 ++ include/linux/of_graph.h | 66 +++ include/media/v4l2-of.h | 33 +- 13 files changed, 397 insertions(+), 178 deletions(-) create mode 100644 Documentation/devicetree/bindings/graph.txt create mode 100644 include/linux/of_graph.h -- 1.8.5.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
[PATCH v5 6/7] of: Implement simplified graph binding for single port devices
For simple devices with only one port, it can be made implicit.
The endpoint node can be a direct child of the device node.
Signed-off-by: Philipp Zabel
---
drivers/of/base.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ba3cfca..7d9c62b 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2037,8 +2037,13 @@ struct device_node *of_graph_get_next_endpoint(const
struct device_node *parent,
struct device_node *node;
/*
* It's the first call, we have to find a port subnode
-* within this node or within an optional 'ports' node.
+* within this node or within an optional 'ports' node,
+* or at least a single endpoint.
*/
+ endpoint = of_get_child_by_name(parent, "endpoint");
+ if (endpoint)
+ return endpoint;
+
node = of_get_child_by_name(parent, "ports");
if (node)
parent = node;
@@ -2049,8 +2054,6 @@ struct device_node *of_graph_get_next_endpoint(const
struct device_node *parent,
/* Found a port, get an endpoint. */
endpoint = of_get_next_child(port, NULL);
of_node_put(port);
- } else {
- endpoint = NULL;
}
if (!endpoint)
@@ -2065,6 +2068,10 @@ struct device_node *of_graph_get_next_endpoint(const
struct device_node *parent,
if (WARN_ONCE(!port, "%s(): endpoint has no parent node\n",
__func__))
return NULL;
+ if (port == parent) {
+ of_node_put(port);
+ return NULL;
+ }
/* Avoid dropping prev node refcount to 0. */
of_node_get(prev);
@@ -2105,9 +2112,11 @@ struct device_node *of_graph_get_remote_port_parent(
/* Get remote endpoint node. */
np = of_parse_phandle(node, "remote-endpoint", 0);
- /* Walk 3 levels up only if there is 'ports' node. */
+ /* Walk 3 levels up only if there is 'ports' node */
for (depth = 3; depth && np; depth--) {
np = of_get_next_parent(np);
+ if (depth == 3 && of_node_cmp(np->name, "port"))
+ break;
if (depth == 2 && of_node_cmp(np->name, "ports"))
break;
}
@@ -2130,6 +2139,11 @@ struct device_node *of_graph_get_remote_port(const
struct device_node *node)
np = of_parse_phandle(node, "remote-endpoint", 0);
if (!np)
return NULL;
- return of_get_next_parent(np);
+ np = of_get_next_parent(np);
+ if (of_node_cmp(np->name, "port")) {
+ of_node_put(np);
+ return NULL;
+ }
+ return np;
}
EXPORT_SYMBOL(of_graph_get_remote_port);
--
1.8.5.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
[PATCH v5 7/7] of: Document simplified graph binding for single port devices
For simple devices with only one port, it can be made implicit.
The endpoint node can be a direct child of the device node.
Signed-off-by: Philipp Zabel
---
Documentation/devicetree/bindings/graph.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/graph.txt
b/Documentation/devicetree/bindings/graph.txt
index 554865b..6dfaff8 100644
--- a/Documentation/devicetree/bindings/graph.txt
+++ b/Documentation/devicetree/bindings/graph.txt
@@ -84,6 +84,14 @@ device {
};
};
+For devices with only a single port and a single endpoint, this can be further
+simplified by making the port implicit, and adding the endpoint node as a
direct
+child of the device node.
+
+device {
+ endpoint { ... };
+};
+
Links between endpoints
---
--
1.8.5.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
[PATCH v5 2/7] Documentation: of: Document graph bindings
The device tree graph bindings as used by V4L2 and documented in
Documentation/device-tree/bindings/media/video-interfaces.txt contain
generic parts that are not media specific but could be useful for any
subsystem with data flow between multiple devices. This document
describe the generic bindings.
Signed-off-by: Philipp Zabel
---
Changes since v4:
- Differentiate from graphs made by simple phandle links
- Do not mention data flow except in video-interfaces example
-
---
Documentation/devicetree/bindings/graph.txt | 129
1 file changed, 129 insertions(+)
create mode 100644 Documentation/devicetree/bindings/graph.txt
diff --git a/Documentation/devicetree/bindings/graph.txt
b/Documentation/devicetree/bindings/graph.txt
new file mode 100644
index 000..554865b
--- /dev/null
+++ b/Documentation/devicetree/bindings/graph.txt
@@ -0,0 +1,129 @@
+Common bindings for device graphs
+
+General concept
+---
+
+The hierarchical organisation of the device tree is well suited to describe
+control flow to devices, but there can be more complex connections between
+devices that work together to form a logical compound device, following an
+arbitrarily complex graph.
+There already is a simple directed graph between devices tree nodes using
+phandle properties pointing to other nodes to describe connections that
+can not be inferred from device tree parent-child relationships. The device
+tree graph bindings described herein abstract more complex devices that can
+have multiple specifiable ports, each of which can be linked to one or more
+ports of other devices.
+
+These common bindings do not contain any information about the direction of
+type of the connections, they just map their existence. Specific properties
+may be described by specialized bindings depending on the type of connection.
+
+To see how this binding applies to video pipelines, for example, see
+Documentation/device-tree/bindings/media/video-interfaces.txt.
+Here the ports describe data interfaces, and the links between them are
+the connecting data buses. A single port with multiple connections can
+correspond to multiple devices being connected to the same physical bus.
+
+Organisation of ports and endpoints
+---
+
+Ports are described by child 'port' nodes contained in the device node.
+Each port node contains an 'endpoint' subnode for each remote device port
+connected to this port. If a single port is connected to more than one
+remote device, an 'endpoint' child node must be provided for each link.
+If more than one port is present in a device node or there is more than one
+endpoint at a port, or a port node needs to be associated with a selected
+hardware interface, a common scheme using '#address-cells', '#size-cells'
+and 'reg' properties is used number the nodes.
+
+device {
+...
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+endpoint@0 {
+ reg = <0>;
+ ...
+ };
+endpoint@1 {
+ reg = <1>;
+ ...
+ };
+};
+
+port@1 {
+ reg = <1>;
+
+ endpoint { ... };
+ };
+};
+
+All 'port' nodes can be grouped under an optional 'ports' node, which
+allows to specify #address-cells, #size-cells properties for the 'port'
+nodes independently from any other child device nodes a device might
+have.
+
+device {
+...
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+...
+endpoint@0 { ... };
+endpoint@1 { ... };
+};
+
+port@1 { ... };
+};
+};
+
+Links between endpoints
+---
+
+Each endpoint should contain a 'remote-endpoint' phandle property that points
+to the corresponding endpoint in the port of the remote device. In turn, the
+remote endpoint should contain a 'remote-endpoint' property. If it has one,
+it must not point to another than the local endpoint. Two endpoints with their
+'remote-endpoint' phandles pointing at each other form a link between the
+containing ports.
+
+device_1 {
+port {
+device_1_output: endpoint {
+remote-endpoint = <&device_2_input>;
+};
+};
+};
+
+device_1 {
+port {
+device_2_input: endpoint {
+remote-endpoint = <&device_1_output>;
+};
+};
+};
+
+
+Required properties
+---
+
+If there is more than one 'port' or more than one 'endpoint' node or 'reg'
+property is present in port and/or endpoint nodes the following properties
+are required in a relevant pa
Re: [PATCH v2 3/3] arm64: Add architecture support for PCI
On Thu, Feb 27, 2014 at 04:06:24PM +, Arnd Bergmann wrote:
> On Thursday 27 February 2014 13:09:59 Liviu Dudau wrote:
>
> > +/*
> > + * PCI address space differs from physical memory address space
> > + */
> > +#define PCI_DMA_BUS_IS_PHYS(0)
> > +
> > +extern int isa_dma_bridge_buggy;
>
> I got curious about isa_dma_bridge_buggy: apparently this is a quirk for
> some old x86 bridges. We don't have those on arm64, and we also don't have
> ISA_DMA_API, so just define this to (0).
OK.
>
> > +static inline int pci_domain_nr(struct pci_bus *bus)
> > +{
> > + struct pci_host_bridge *bridge = to_pci_host_bridge(bus->bridge);
> > +
> > + if (bridge)
> > + return bridge->domain_nr;
> > +
> > + return 0;
> > +}
> > +
> > +static inline int pci_proc_domain(struct pci_bus *bus)
> > +{
> > + return pci_domain_nr(bus);
> > +}
>
> And this one I would change to always return '1': we can deal with
> domain numbers showing up in /procfs for all buses, since there is
> no legacy software to worry about.
Will do, thanks for reviewing this.
>
> > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > new file mode 100644
> > index 000..496df41
> > --- /dev/null
> > +++ b/arch/arm64/kernel/pci.c
> > @@ -0,1 +1,126 @@
>
> Ok, this is nice and short. Let's see if we can reduce it to nothing ;-)
>
> > +/*
> > + * Called after each bus is probed, but before its children are examined
> > + */
> > +void pcibios_fixup_bus(struct pci_bus *bus)
> > +{
> > + struct pci_dev *dev;
> > + struct resource *res;
> > + int i;
> > +
> > + if (!pci_is_root_bus(bus)) {
> > + pci_read_bridge_bases(bus);
> > +
> > + pci_bus_for_each_resource(bus, res, i) {
> > + if (!res || !res->flags || res->parent)
> > + continue;
> > +
> > + /*
> > +* If we are going to reassign everything, we can
> > +* shrink the P2P resource to have zero size to
> > +* save space
> > +*/
> > + if (pci_has_flag(PCI_REASSIGN_ALL_RSRC)) {
> > + res->flags |= IORESOURCE_UNSET;
> > + res->start = 0;
> > + res->end = -1;
> > + continue;
> > + }
> > + }
> > + }
> > +
> > + list_for_each_entry(dev, &bus->devices, bus_list) {
> > + /* Ignore fully discovered devices */
> > + if (dev->is_added)
> > + continue;
> > +
> > + set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
> > +
> > + /* Read default IRQs and fixup if necessary */
> > + dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > + }
> > +}
> > +EXPORT_SYMBOL(pcibios_fixup_bus);
>
> Shrinking the P2P resources I suppose is optional, but everything
> else is in fact needed for any DT based architecture. Could this
> be turned into a generic helper function in the PCI core that we
> can call from architecture code?
>
> If you name it pci_generic_fixup_bus(), we can add a weak helper
> like:
>
> void __weak pcibios_fixup_bus(struct pci_bus *bus)
> {
> pci_generic_fixup_bus(bus);
> }
>
> for architectures like arm64 that don't actually need to do anything
> else.
Sure, it can be done. Don't know what is the policy for these kind of functions
that are used by architectures, but I can try sending a patch that adds the
weak implementations in the core PCI code.
>
> > +/*
> > + * We don't have to worry about legacy ISA devices, so nothing to do here
> > + */
> > +resource_size_t pcibios_align_resource(void *data, const struct resource
> > *res,
> > + resource_size_t size, resource_size_t align)
> > +{
> > + return ALIGN(res->start, align);
> > +}
> > +EXPORT_SYMBOL(pcibios_align_resource);
>
> Where did this come from?
>From an internal version that Will posted. See, we do talk to each other ;)
> The most common implementation seems to be
>
> resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> resource_size_t size, resource_size_t align)
> {
> return start;
> }
> EXPORT_SYMBOL(pcibios_align_resource);
>
> if you don't have to worry about ISA devices. The ALIGN() part seems to
> be handled by __find_resource() already.
>
> I'd say that should be made the default implementation in the PCI core.
>
> I'm also pretty sure you don't need the EXPORT_SYMBOL, since the PCI
> core cannot be a loadable module (yet).
OK.
>
> > +int pcibios_enable_device(struct pci_dev *dev, int mask)
> > +{
> > + return pci_enable_resources(dev, mask);
> > +}
> > +
> > +void pcibios_fixup_bridge_ranges(struct list_head *resources)
> > +{
> > +}
>
> These are clearly the right implementations, but they should be weak
> functions, too.
pcibios_enable_devices is already subject to a patch series from Bjo
Re: [PATCH v3 2/3] ARM: dts: imx6: extend PCIe interrupt list for MSI
On Thursday 27 February 2014 17:41:44 Lucas Stach wrote: > num-lanes = <1>; > - interrupts = <0 123 0x04>; > + interrupt-names = "inta", "intb", "intc", "intd/msi"; > + interrupts = <0 123 0x04>, <0 122 0x04>, <0 121 > 0x04>, <0 120 0x04>; > clocks = <&clks 189>, <&clks 187>, <&clks 206>, > <&clks 144>; > The standard PCI interrupts should not be listed here, you need to put them into the "interrupt-map" property so the of_irq_parse_and_map_pci() function can translate them. 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 v3 2/3] ARM: dts: imx6: extend PCIe interrupt list for MSI
Add optional irqs, necessary for MSI handling. Signed-off-by: Juergen Beisert Signed-off-by: Lucas Stach --- Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 10 +- arch/arm/boot/dts/imx6qdl.dtsi | 3 ++- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt index aade8d29314c..3b27ec310ec4 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt @@ -16,6 +16,13 @@ Required properties: - "pcie_axi" Optional properties: +- interrupts: Must contain an entry for each entry in the + interrupt-names property. +- interrupt-names: May include the following entries: + - "inta" + - "intb" + - "intc" + - "intd/msi" if not present the driver won't be able to handle MSI - power-on-gpio: gpio pin number of power-enable signal - wake-up-gpio: gpio pin number of incoming wakeup signal - disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal @@ -32,7 +39,8 @@ Example: 0x8100 0 0 0x01f8 0 0x0001 0x8200 0 0x0100 0x0100 0 0x00f0>; num-lanes = <1>; - interrupts = <0 123 0x04>; + interrupt-names = "inta", "intb", "intc", "intd/msi"; + interrupts = <0 123 0x04>, <0 122 0x04>, <0 121 0x04>, <0 120 0x04>; clocks = <&clks 189>, <&clks 187>, <&clks 206>, <&clks 144>; clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_gate", "pcie_axi"; }; diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi index fb28b2ecb1db..e0261dd3fdd3 100644 --- a/arch/arm/boot/dts/imx6qdl.dtsi +++ b/arch/arm/boot/dts/imx6qdl.dtsi @@ -126,7 +126,8 @@ 0x8100 0 0 0x01f8 0 0x0001 /* downstream I/O */ 0x8200 0 0x0100 0x0100 0 0x00f0>; /* non-prefetchable memory */ num-lanes = <1>; - interrupts = <0 123 0x04>; + interrupt-names = "inta", "intb", "intc", "intd/msi"; + interrupts = <0 123 0x04>, <0 122 0x04>, <0 121 0x04>, <0 120 0x04>; clocks = <&clks 189>, <&clks 187>, <&clks 206>, <&clks 144>; clock-names = "pcie_ref_125m", "sata_ref_100m", "lvds_gate", "pcie_axi"; status = "disabled"; -- 1.8.5.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
[PATCH v3 3/3] PCI: imx6: add support for MSI
This patch adds support for Message Signaled Interrupt in the
imx6q-pcie driver. It is done in a similar way as for the Exynos
PCIe driver (commit f342d940ee0e3a2b5197fd4fbade1cb6bbc960b7),
which is also using the Synopsys designware PCIe IP core.
Signed-off-by: Harro Haan
Signed-off-by: Juergen Beisert
Signed-off-by: Lucas Stach
---
drivers/pci/host/pci-imx6.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index ee082509b0ba..50f76581bcfb 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "pcie-designware.h"
@@ -329,6 +330,17 @@ static int imx6_pcie_wait_for_link(struct pcie_port *pp)
return 0;
}
+/* legacy IRQD/MSI interrupt */
+static irqreturn_t imx6_pcie_irqd_msi_handler(int irq, void *arg)
+{
+ struct pcie_port *pp = arg;
+
+ if (IS_ENABLED(CONFIG_PCI_MSI))
+ dw_handle_msi_irq(pp);
+
+ return IRQ_HANDLED;
+}
+
static int imx6_pcie_start_link(struct pcie_port *pp)
{
struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
@@ -403,6 +415,9 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
dw_pcie_setup_rc(pp);
imx6_pcie_start_link(pp);
+
+ if (IS_ENABLED(CONFIG_PCI_MSI) && (pp->msi_irq >= 0))
+ dw_pcie_msi_init(pp);
}
static void imx6_pcie_reset_phy(struct pcie_port *pp)
@@ -498,6 +513,21 @@ static int imx6_add_pcie_port(struct pcie_port *pp,
return -ENODEV;
}
+ if (IS_ENABLED(CONFIG_PCI_MSI)) {
+ pp->msi_irq = platform_get_irq_byname(pdev, "intd/msi");
+ if (pp->msi_irq < 0) {
+ dev_info(&pdev->dev, "failed to get INTD/MSI, PCIe will
not support MSI\n");
+ } else {
+ ret = devm_request_irq(&pdev->dev, pp->msi_irq,
+ imx6_pcie_irqd_msi_handler,
+ IRQF_SHARED, "mx6-pcie-msi", pp);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to request INTD/MSI
irq\n");
+ return -ENODEV;
+ }
+ }
+ }
+
pp->root_bus_nr = -1;
pp->ops = &imx6_pcie_host_ops;
--
1.8.5.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
[PATCH v3 1/3] PCI: designware: split samsung and fsl bindings
The glue around the core designware IP is
significantly different between the Exynos and
i.MX, which is reflected in the DT bindings.
Note that this patch doesn't change any bindings,
but just alters the documentation to match reality
of deployed DTs and kernels.
Signed-off-by: Lucas Stach
---
.../devicetree/bindings/pci/designware-pcie.txt| 69 +
.../devicetree/bindings/pci/fsl,imx6q-pcie.txt | 38
.../bindings/pci/samsung,exynos5440-pcie.txt | 70 ++
3 files changed, 109 insertions(+), 68 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
create mode 100644
Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index d6fae13ff062..8274c80fe874 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -1,15 +1,7 @@
* Synopsys Designware PCIe interface
Required properties:
-- compatible: should contain "snps,dw-pcie" to identify the
- core, plus an identifier for the specific instance, such
- as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
-- reg: base addresses and lengths of the pcie controller,
- the phy controller, additional register for the phy controller.
-- interrupts: interrupt values for level interrupt,
- pulse interrupt, special interrupt.
-- clocks: from common clock binding: handle to pci clock.
-- clock-names: from common clock binding: should be "pcie" and "pcie_bus".
+- compatible: should contain "snps,dw-pcie" to identify the core.
- #address-cells: set to <3>
- #size-cells: set to <2>
- device_type: set to "pci"
@@ -22,62 +14,3 @@ Required properties:
Optional properties:
- reset-gpio: gpio pin number of power good signal
-
-Optional properties for fsl,imx6q-pcie
-- power-on-gpio: gpio pin number of power-enable signal
-- wake-up-gpio: gpio pin number of incoming wakeup signal
-- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal
-
-Example:
-
-SoC specific DT Entry:
-
- pcie@29 {
- compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
- reg = <0x29 0x1000
- 0x27 0x1000
- 0x271000 0x40>;
- interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
- clocks = <&clock 28>, <&clock 27>;
- clock-names = "pcie", "pcie_bus";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- ranges = <0x0800 0 0x4000 0x4000 0 0x1000 /*
configuration space */
- 0x8100 0 0 0x40001000 0 0x0001 /*
downstream I/O */
- 0x8200 0 0x40011000 0x40011000 0 0x1ffef000>; /*
non-prefetchable memory */
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0x0 0 &gic 53>;
- num-lanes = <4>;
- };
-
- pcie@2a {
- compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
- reg = <0x2a 0x1000
- 0x272000 0x1000
- 0x271040 0x40>;
- interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
- clocks = <&clock 29>, <&clock 27>;
- clock-names = "pcie", "pcie_bus";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- ranges = <0x0800 0 0x6000 0x6000 0 0x1000 /*
configuration space */
- 0x8100 0 0 0x60001000 0 0x0001 /*
downstream I/O */
- 0x8200 0 0x60011000 0x60011000 0 0x1ffef000>; /*
non-prefetchable memory */
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0x0 0 &gic 56>;
- num-lanes = <4>;
- };
-
-Board specific DT Entry:
-
- pcie@29 {
- reset-gpio = <&pin_ctrl 5 0>;
- };
-
- pcie@2a {
- reset-gpio = <&pin_ctrl 22 0>;
- };
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
new file mode 100644
index ..aade8d29314c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
@@ -0,0 +1,38 @@
+* Freescale i.MX6 PCIe interface
+
+This PCIe host controller is based on the Synopsis Designware PCIe IP
+and thus inherits all the common properties defined in designware-pcie.txt.
+
+Required properties:
+- compatible: "fsl,imx6q-pcie"
+- reg: base addresse and length of the pcie controller
+- interrupts: Must contain interrupt handle for controller INTA output.
+
