Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver
On 2015. 8. 20., at PM 3:23, Yakir Yang wrote: > > Hi Jingoo & Archit, > > >> On 08/20/2015 12:54 AM, Jingoo Han wrote: >>> On 2015. 8. 20., at PM 1:29, Archit Taneja wrote: >>> Hi, >>> On 08/19/2015 08:18 PM, Yakir Yang wrote: Hi all, The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller share the same IP, so a lot of parts can be re-used. I split the common code into bridge directory, then rk3288 and exynos only need to keep some platform code. Cause I can't find the exact IP name of exynos dp controller, so I decide to name dp core driver with "analogix" which I find in rk3288 eDP TRM ;) Beyond that, there are three light registers setting differents bewteen exynos and rk3288. 1. RK3288 have five special pll resigters which not indicata in exynos dp controller. 2. The address of DP_PHY_PD(dp phy power manager register) are different between rk3288 and exynos. 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug register). I have verified this series on two kinds of rockchip platform board, one is rk3288 sdk board which connect with a 2K display port monitor, the other is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2", both of them works rightlly. I haven't verified the dp function on samsung platform, cause I haven't got exynos boards. I can only ensure that there are no build error on samsung platform, wish some samsung guys help to test. ;) Thanks, - Yakir Changes in v3: - Take Thierry Reding suggest, move exynos's video_timing code to analogix_dp-exynos platform driver, add get_modes method to struct analogix_dp_plat_data. - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*". - Take Thierry Reding suggest, dynamic parse video timing info from struct drm_display_mode and struct drm_display_info. - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to the DT property value directly, but we can take those as hardware limite. For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would like "link-rate = 0x0a" "lane-count = 4". - Take Heiko suggest, add devicetree binding documents. - Take Thierry Reding suggest, remove sync pol & colorimetry properies from the new analogix dp driver devicetree binding. - Update the exist exynos dtsi file with the latest DP DT properies. - Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp core driver which name to "dp", and leave "pclk_edp" to rockchip dp platform driver which name to "pclk". - Take Heiko suggest, add devicetree binding document. - Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote point to get panel node. - Add the new function point analogix_dp_platdata.get_modes init. - Take Heiko suggest, add rockchip dp phy driver, collect the phy clocks and power control. - Add "analogix,need-force-hpd" to indicate whether driver need foce hpd when hpd detect failed. - move dp hpd detect to connector detect function. - Add edid modes parse support Changes in v2: - Take Joe Preches advise, improved commit message more readable, and avoid using some uncommon style like bellow: - retval = exynos_dp_read_bytes_from_i2c(... ...) + retval = + exynos_dp_read_bytes_from_i2c(..); - Take Jingoo Han suggest, just remove my name from author list. - Take Jingoo Han suggest, remove new copyright - Fix compiled failed dut to analogix_dp_device misspell - Take Heiko suggest, get panel node with remote-endpoint method, and create devicetree binding for driver. - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m", leave those clock to rockchip dp phy driver. - Add GNU license v2 declared and samsung copyright - Fix compile failed dut to phy_pd_addr variable misspell error Yakir Yang (14): drm: exynos/dp: fix code style drm: exynos/dp: convert to drm bridge mode drm: bridge: analogix_dp: split exynos dp driver to bridge dir drm: bridge/analogix_dp: dynamic parse sync_pol & interlace & colorimetry drm: bridge/analogix_dp: fix link_rate & lane_count bug Documentation: drm/bridge: add document for analogix_dp drm: rockchip/dp: add rockchip platform dp driver phy: Add driver for rockchip Display Port PHY drm: bridge/analogix_dp: add platform device type support drm: bridge: analogix_dp: add some rk3288 special registers setting drm: bridge: analogix_dp:
Re: [PATCH v1 2/4] dmaengine: xgene-dma: Add support for CRC32C calculation via DMA engine
Hi Vinod,
On Thu, Aug 20, 2015 at 11:10 AM, Vinod Koul wrote:
> On Thu, Jul 30, 2015 at 05:41:06PM +0530, Rameshwar Prasad Sahu wrote:
>> + /* Invalidate unused source address field */
>> + for (; i < 4; i++)
>> + xgene_dma_invalidate_buffer(xgene_dma_lookup_ext8(desc2, i));
>> +
>> + /* Check whether requested buffer processed */
>> + if (nbytes) {
>> + chan_err(chan, "Src count crossed maximum limit\n");
>> + return -EINVAL;
> no cleanup ?
Here not required, cleanup I am doing in parent function from where
this function is getting called in case of failure.
>
>> +struct dma_async_tx_descriptor *xgene_dma_prep_flyby(
>> + struct xgene_dma_chan *chan, struct scatterlist *src_sg,
>> + size_t len, u32 seed, u8 *result, unsigned long flags, u8 opcode)
> please fix style here
Could you explain me What kind of coding style you would like here ??
>
>> +struct dma_async_tx_descriptor *xgene_dma_prep_crc32c(
>> + struct dma_chan *dchan, struct scatterlist *src_sg,
>> + size_t len, u32 seed, u8 *result, unsigned long flags)
> here too
>
>> @@ -1309,8 +1512,13 @@ static void xgene_dma_setup_ring(struct
>> xgene_dma_ring *ring)
>> ring->pdma->csr_ring + XGENE_DMA_RING_ID);
>>
>> /* Set DMA ring buffer */
>> - iowrite32(XGENE_DMA_RING_ID_BUF_SETUP(ring->num),
>> - ring->pdma->csr_ring + XGENE_DMA_RING_ID_BUF);
>> + ring_id_buf = XGENE_DMA_RING_ID_BUF_SETUP(ring->num);
>> +
>> + if (ring->is_bufpool)
>> + ring_id_buf |= XGENE_DMA_RING_IS_BUFPOOL;
>> +
>> + iowrite32(ring_id_buf, ring->pdma->csr_ring +
>> + XGENE_DMA_RING_ID_BUF);
> pls fix style here
I didn't see any alignment issue here, just follow checkpatch that
argument should start just after "function(" in next line also.
>
> --
> ~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/8] arm64, numa: Add numa support for arm64 platforms.
Hi Maintainers, On Fri, Aug 14, 2015 at 10:14 PM, Ganapatrao Kulkarni wrote: > On Fri, Aug 14, 2015 at 10:09 PM, Ganapatrao Kulkarni > wrote: >> v5: >> - created base verion of numa.c which creates dummy numa without >> using dt >> on single socket platforms. Then added patches for dt support. >> - Incorporated review comments from Hanjun Guo. >> >> v4: >> done changes as per Arnd review comments. >> >> v3: >> Added changes to support numa on arm64 based platforms. >> Tested these patches on cavium's multinode(2 node topology) platform. >> In this patchset, defined and implemented dt bindings for numa mapping >> for core and memory using device node property arm,associativity. >> >> v2: >> Defined and implemented numa map for memory, cores to node and >> proximity distance matrix of nodes. >> >> v1: >> Initial patchset to support numa on arm64 platforms. >> >> Note: >> 1. This patchset is tested for numa with dt on >>thunderx single socket and dual socket boards. >> 2. Numa DT booting needs the dt memory nodes, which are deleted in >> current efi-stub, >> hence to try numa with dt, you need to rebase with ard's patchset. >> >> http://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-uefi-early-fdt-handling >> >> >> Ganapatrao Kulkarni (4): >> arm64, numa: adding numa support for arm64 platforms. >> Documentation: arm64/arm: dt bindings for numa. >> arm64, numa: adding numa support for arm64 platforms. >> arm64, dt, thunderx: Add initial dts for Cavium Thunder SoC in 2 Node >> topology. >> >> Documentation/devicetree/bindings/arm/numa.txt | 212 +++ >> arch/arm64/Kconfig | 32 + >> arch/arm64/boot/dts/cavium/Makefile | 2 +- >> arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts | 78 +++ >> arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi | 790 >> >> arch/arm64/include/asm/mmzone.h | 32 + >> arch/arm64/include/asm/numa.h | 49 ++ >> arch/arm64/kernel/Makefile | 1 + >> arch/arm64/kernel/dt_numa.c | 316 ++ >> arch/arm64/kernel/setup.c | 9 + >> arch/arm64/kernel/smp.c | 3 + >> arch/arm64/mm/Makefile | 1 + >> arch/arm64/mm/init.c| 34 +- >> arch/arm64/mm/numa.c| 563 + >> 14 files changed, 2115 insertions(+), 7 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/arm/numa.txt >> create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts >> create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi >> create mode 100644 arch/arm64/include/asm/mmzone.h >> create mode 100644 arch/arm64/include/asm/numa.h >> create mode 100644 arch/arm64/kernel/dt_numa.c >> create mode 100644 arch/arm64/mm/numa.c >> >> -- >> 1.8.1.4 >> > sorry, minor correction, this patchset has 4 patches. > > PATCH v5 0/8 => PATCH v5 0/4 please review this patchset. thanks Ganapat -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] ARM: dts: sun8i: Add support for qt90h-v4 tablets
On Fri, Aug 14, 2015 at 04:44:37PM +0200, Hans de Goede wrote: > The gt90h is a pcb found in generic 9" tablets with an A23 soc, 1G RAM > and 8G nand, rtl8723as usb wifi, 1 micro usb port and 1 micro sd slot. > > This commit adds a dts for v4 of the gt90h pcb. > > Signed-off-by: Hans de Goede Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 4/6] ARM: dts: sun7i: Enable USB DRC on pcDuino 3
On Fri, Aug 14, 2015 at 04:44:35PM +0200, Hans de Goede wrote: > From: Jelle van der Waa > > Enable the otg/drc usb controller on the pcDuino 3. > > Note this board has the otg-vbus connected directly to the 5v-dcc of > the board, so there is no vbus0 regulator, nor vbus0-det. Can it do OTG then? If VBUS is tied to the 5v, there's no way for the board to shut it down when acting as peripheral, right? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 3/6] ARM: dts: sun7i: Add regulator configuration to the pcduino3 dts file
On Fri, Aug 14, 2015 at 04:44:34PM +0200, Hans de Goede wrote: > From: Jelle van der Waa > > Add regulator configuration to the pcduino3 dts file. > > Signed-off-by: Jelle van der Waa > Signed-off-by: Hans de Goede Queued, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 1/6] ARM: dts: sun5i: Add simplefb node for tvencoder output
Hi, On Fri, Aug 14, 2015 at 04:44:32PM +0200, Hans de Goede wrote: > Add a simplefb node for tvencoder / composite-video output, such as found > on the Auxtek-T003 and the CHIP. > > Signed-off-by: Hans de Goede Queued, thanks! I guess the CHIP will have to have the same change for the A13 DTSI. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH] usb: musb: omap2430: use *syscon* framework API to write to mailbox register
Hi, On Thursday 06 August 2015 02:17 PM, Tony Lindgren wrote: > * Kishon Vijay Abraham I [150805 07:10]: >> On Wednesday 05 August 2015 01:31 PM, Tony Lindgren wrote: >>> >>> We don't have syscon-otghs and to me it seems we need a PHY driver >>> as I pointed out at: >> >> If *syscon-otghs* is not present, then it'll fall-back to using the >> *ctrl-module*. > > OK great. > >>> >>> https://lkml.org/lkml/2015/6/24/231 >> >> Maybe I should have explained this in the previous thread. The *otghs* >> register >> that we are trying to access here does _not_ belong to the PHY. It acts as >> mailbox register from MUSB glue (TI integration layer) to MUSB core. That's >> why >> it's programmed in the TI glue layer (omap2430.c). >> >> Even when we were using the older API [omap_control_usb_set_mode()], we first >> call omap_musb_mailbox from the PHY drivers (phy-twl4030-usb.c, >> phy-twl6030-usb.c) and then omap_musb_mailbox in the TI glue writes to the >> control module instead of PHY drivers directly calling >> omap_control_usb_set_mode(). > > Hmm looking at "Table 18-204. CONTROL_USBOTGHS_CONTROL" it seems to mention > "transceiver" for quite a few bitfields :) Probably what that register does > is control a PHY over ULPI. OMAP4 uses UTMI PHY and it uses CONTROL_USBOTGHS_CONTROL too. > > So from Linux kernel point of view we're best off treating it as a PHY. > It seems it should have a minimal PHY driver similar to what we have for > dm816x control module in drivers/phy/phy-dm816x-usb.c. hmm.. IMHO CONTROL_USBOTGHS_CONTROL register belongs to the TI MUSB glue and should be programmed in omap2430.c. It's better to get the opinion of Felipe here. Felipe? > > For reference, here is the register bitfields pasted from 4460 TRM: > > Table 18-204. CONTROL_USBOTGHS_CONTROL, p3972 > Physical Address 0x4A00 233C > > BIT NAMEDESCIPTION > 8 DISCHRGVBUS ... OTG transceiver does (not) discharge VBUS ... > 7 CHRGVBUS... OTG transceiver does (not) charge VBUS ... > 6 IDPULLUP... OTG transceiver does (not) drive VBUS ... > 4 IDDIG ... OTG transceiver does (not) apply a pullup to ID ... > 3 SESSEND ... VBUS voltage is above/below VB_SESS_END ... > 2 VBUSVALID ... VBUS is above the threshold ... > 1 BVALID ... VBUS voltage is above/below VB_SESS_VLD ... > 0 AVALID ... BUS voltage is above/below VA_SESS_VLD ... > > So how about just adding ONTROL_USBOTGHS_CONTROL support to the existing > drivers/phy/phy-omap-usb2.c instead? It seems that it should allow us > to completely get rid of the custom mailbox stuff for MUSB 2430 support? Not in phy-omap-usb2.c. It's the UTMI PHY driver and is not used by OMAP3 based boards (uses twl4030 ULPI PHY). CONTROL_USBOTGHS_CONTROL has to be programmed for OMAP3 also. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] dma: Add Xilinx zynqmp dma engine driver support
On Thu, Aug 20, 2015 at 11:43 AM, Vinod Koul wrote:
> On Thu, Aug 06, 2015 at 08:49:33AM +0530, Punnaiah Choudary Kalluri wrote:
>
>> + list_for_each_entry_safe(desc, next, &chan->done_list, node) {
>> + dma_async_tx_callback callback;
>> + void *callback_param;
>> +
>> + list_del(&desc->node);
>> +
>> + callback = desc->async_tx.callback;
>> + callback_param = desc->async_tx.callback_param;
>> + if (callback) {
>> + if (in_interrupt())
>> + spin_unlock_bh(&chan->lock);
>> + else
>> + spin_unlock(&chan->lock);
>
> This looks bad!
> Why would callback be called from different context. It should only be
> invoked from your tasklet
During the terminate call, driver need to clean up the existing BDs so that time
this function will be called from the thread or process context in
addition to the
tasklet context.
DO you have any suggestion here ?
>
>> +static int zynqmp_dma_device_terminate_all(struct dma_chan *dchan)
>> +{
>> + struct zynqmp_dma_chan *chan = to_chan(dchan);
>> +
>> + spin_lock_bh(&chan->lock);
>> + zynqmp_dma_reset(chan);
>> + spin_unlock_bh(&chan->lock);
>
> No descriptor cleanup
zynqmp_dma_reset will do the descriptor cleanup.
>
>> +static void zynqmp_dma_chan_remove(struct zynqmp_dma_chan *chan)
>> +{
>> + if (!chan)
>> + return;
>> +
>> + devm_free_irq(chan->zdev->dev, chan->irq, chan);
>> + tasklet_kill(&chan->tasklet);
>> + list_del(&chan->common.device_node);
>
> not deregistering with dmaengine?
This i am doing it in zynqmp_dma_remove function. Each channel will be
a standalone dma device for ZynqMP DMA case
>
>> + zdev->chan = chan;
>> + tasklet_init(&chan->tasklet, zynqmp_dma_do_tasklet, (ulong)chan);
>> + spin_lock_init(&chan->lock);
>> + INIT_LIST_HEAD(&chan->active_list);
>> + INIT_LIST_HEAD(&chan->pending_list);
>> + INIT_LIST_HEAD(&chan->done_list);
>> + INIT_LIST_HEAD(&chan->free_list);
>
> You can simmplify this by using vchan framework!
I got your point . but i have already said my reasons why i am
reluctant to use vchan framework in v3 review.
>
>> +MODULE_AUTHOR("Xilinx, Inc.");
>> +MODULE_DESCRIPTION("Xilinx ZynqMP DMA driver");
>> +MODULE_LICENSE("GPL");
> No alias, how did it get loaded?
I will fix this. thanks.
Regards,
Punnaiah
>
> --
> ~Vinod
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/4] dmaengine: Add support for new feature CRC32C
Hi Vinod, On Thu, Aug 20, 2015 at 10:56 AM, Vinod Koul wrote: > On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote: >> This patch adds support for new feature CRC32C calculation in >> dmaengine framework. > > Looks okay can you please update Documentation also Thanks, I will update Documentation. > > -- > ~Vinod > -- To unsubscribe from this list: send the line "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] phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver
This patch adds support for R-Car generation 3 USB2 PHY driver.
This SoC has 3 EHCI/OHCI channels, and the channel 0 is shared
with the HSUSB (USB2.0 peripheral) device.
So, the purpose of this driver is:
1) initializes some registers of SoC specific to use the
{ehci,ohci}-platform driver.
2) detects id pin to select host or peripheral on the channel 0.
For now, this driver only supports 1) above.
Signed-off-by: Yoshihiro Shimoda
---
.../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 37 +++
drivers/phy/Kconfig| 6 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-rcar-gen3-usb2.c | 262 +
4 files changed, 306 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
create mode 100644 drivers/phy/phy-rcar-gen3-usb2.c
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
new file mode 100644
index 000..1e8437f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -0,0 +1,37 @@
+* Renesas R-Car generation 3 USB 2.0 PHY
+
+This file provides information on what the device node for the R-Car generation
+3 USB 2.0 PHY contains.
+
+Required properties:
+- compatible: "renesas,usb2-phy-r8a7795" if the device is a part of R8A7795
SoC.
+- reg: offset and length of the USB2.0 host register block.
+- reg-names: must be "usb2".
+- clocks: clock phandle and specifier pair.
+- clock-names: string, clock input name, must be "usb2", and optional "hsusb".
+- #phy-cells: see phy-bindings.txt in the same directory, must be <0>.
+
+Optional proparies:
+To use a USB channel which EHCI/OHCI and HSUSB are combined, the device tree
+node should set HSUSB proparies to reg and reg-names proparies:
+- reg: offset and length of the HSUSB register block.
+- reg-names: must be "hsusb".
+
+Example (R-Car H3):
+
+ usb-phy@ee080200 {
+ compatible = "renesas,usb2-phy-r8a7795";
+ reg = <0 0xee080200 0 0x6ff>, <0 0xe6590100 0 0x100>;
+ reg-names = "usb2", "hsusb";
+ clocks = <&mstp7_clks R8A7795_CLK_EHCI0>,
+<&mstp7_clks R8A7795_CLK_HSUSB>;
+ clock-names = "usb2", "hsusb";
+ };
+
+ usb-phy@ee0a0200 {
+ compatible = "renesas,usb2-phy-r8a7795";
+ reg = <0 0xee0a0200 0 0x6ff>;
+ reg-names = "usb2";
+ clocks = <&mstp7_clks R8A7795_CLK_EHCI0>;
+ clock-names = "usb2";
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 47da573..ee300fa 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -118,6 +118,12 @@ config PHY_RCAR_GEN2
help
Support for USB PHY found on Renesas R-Car generation 2 SoCs.
+config PHY_RCAR_GEN3_USB2
+ tristate "Renesas R-Car generation 3 USB 2.0 PHY driver"
+ depends on GENERIC_PHY
+ help
+ Support for USB 2.0 PHY found on Renesas R-Car generation 3 SoCs.
+
config OMAP_CONTROL_PHY
tristate "OMAP CONTROL PHY Driver"
depends on ARCH_OMAP2PLUS || COMPILE_TEST
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a5b18c1..97e83bc 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
obj-$(CONFIG_PHY_MIPHY28LP)+= phy-miphy28lp.o
obj-$(CONFIG_PHY_MIPHY365X)+= phy-miphy365x.o
obj-$(CONFIG_PHY_RCAR_GEN2)+= phy-rcar-gen2.o
+obj-$(CONFIG_PHY_RCAR_GEN3_USB2) += phy-rcar-gen3-usb2.o
obj-$(CONFIG_OMAP_CONTROL_PHY) += phy-omap-control.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_TI_PIPE3) += phy-ti-pipe3.o
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
new file mode 100644
index 000..e319eaf
--- /dev/null
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -0,0 +1,262 @@
+/*
+ * Renesas R-Car Gen3 for USB2.0 PHY driver
+ *
+ * Copyright (C) 2015 Renesas Electronics Corporation
+ *
+ * This is based on the phy-rcar-gen2 driver:
+ * Copyright (C) 2014 Renesas Solutions Corp.
+ * Copyright (C) 2014 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/*** USB2.0 Host registers (original offset is +0x200) ***/
+#define USB2_INT_ENABLE0x000
+#define USB2_USBCTR0x00c
+#define USB2_SPD_RSM_TIMSET0x10c
+#define USB2_OC_TIMSET 0x110
+
+/* INT_ENABLE */
+#define USB2_INT_ENABLE_USBH_INTB_EN BIT(2)
+#define USB2_INT_ENABLE_USBH_INTA_EN BIT(1)
+#define USB2_INT_ENABLE_INIT
Re: [PATCH] dmaengine: xgene-dma: Add ACPI support for X-Gene DMA engine driver
On Tue, Jul 21, 2015 at 06:44:39PM +0530, Rameshwar Prasad Sahu wrote: > This patch adds ACPI support for the APM X-Gene DMA engine driver. Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver
Hi Jingoo & Archit, On 08/20/2015 12:54 AM, Jingoo Han wrote: On 2015. 8. 20., at PM 1:29, Archit Taneja wrote: Hi, On 08/19/2015 08:18 PM, Yakir Yang wrote: Hi all, The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller share the same IP, so a lot of parts can be re-used. I split the common code into bridge directory, then rk3288 and exynos only need to keep some platform code. Cause I can't find the exact IP name of exynos dp controller, so I decide to name dp core driver with "analogix" which I find in rk3288 eDP TRM ;) Beyond that, there are three light registers setting differents bewteen exynos and rk3288. 1. RK3288 have five special pll resigters which not indicata in exynos dp controller. 2. The address of DP_PHY_PD(dp phy power manager register) are different between rk3288 and exynos. 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug register). I have verified this series on two kinds of rockchip platform board, one is rk3288 sdk board which connect with a 2K display port monitor, the other is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2", both of them works rightlly. I haven't verified the dp function on samsung platform, cause I haven't got exynos boards. I can only ensure that there are no build error on samsung platform, wish some samsung guys help to test. ;) Thanks, - Yakir Changes in v3: - Take Thierry Reding suggest, move exynos's video_timing code to analogix_dp-exynos platform driver, add get_modes method to struct analogix_dp_plat_data. - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*". - Take Thierry Reding suggest, dynamic parse video timing info from struct drm_display_mode and struct drm_display_info. - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to the DT property value directly, but we can take those as hardware limite. For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would like "link-rate = 0x0a" "lane-count = 4". - Take Heiko suggest, add devicetree binding documents. - Take Thierry Reding suggest, remove sync pol & colorimetry properies from the new analogix dp driver devicetree binding. - Update the exist exynos dtsi file with the latest DP DT properies. - Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp core driver which name to "dp", and leave "pclk_edp" to rockchip dp platform driver which name to "pclk". - Take Heiko suggest, add devicetree binding document. - Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote point to get panel node. - Add the new function point analogix_dp_platdata.get_modes init. - Take Heiko suggest, add rockchip dp phy driver, collect the phy clocks and power control. - Add "analogix,need-force-hpd" to indicate whether driver need foce hpd when hpd detect failed. - move dp hpd detect to connector detect function. - Add edid modes parse support Changes in v2: - Take Joe Preches advise, improved commit message more readable, and avoid using some uncommon style like bellow: - retval = exynos_dp_read_bytes_from_i2c(... ...) + retval = + exynos_dp_read_bytes_from_i2c(..); - Take Jingoo Han suggest, just remove my name from author list. - Take Jingoo Han suggest, remove new copyright - Fix compiled failed dut to analogix_dp_device misspell - Take Heiko suggest, get panel node with remote-endpoint method, and create devicetree binding for driver. - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m", leave those clock to rockchip dp phy driver. - Add GNU license v2 declared and samsung copyright - Fix compile failed dut to phy_pd_addr variable misspell error Yakir Yang (14): drm: exynos/dp: fix code style drm: exynos/dp: convert to drm bridge mode drm: bridge: analogix_dp: split exynos dp driver to bridge dir drm: bridge/analogix_dp: dynamic parse sync_pol & interlace & colorimetry drm: bridge/analogix_dp: fix link_rate & lane_count bug Documentation: drm/bridge: add document for analogix_dp drm: rockchip/dp: add rockchip platform dp driver phy: Add driver for rockchip Display Port PHY drm: bridge/analogix_dp: add platform device type support drm: bridge: analogix_dp: add some rk3288 special registers setting drm: bridge: analogix_dp: try force hpd after plug in lookup failed drm: bridge/analogix_dp: expand the delay time for hpd detect drm: bridge/analogix_dp: move hpd detect to connector detect function drm: bridge/analogix_dp: add edid modes parse in get_modes method .../devicetree/bindings/drm/bridge/analogix_dp.txt | 73 + .../devicetree/bindings/phy/rockchip-dp-phy.txt| 26 + .../bindings/video/analogix_dp-rockchip.txt| 83 ++ .../devicetree/bindings/video/exynos_dp.txt| 51 +- ar
Re: [PATCH 2/3] ARM: dts: sun6i: Turn on gmac on Colombus
Hi, On 08/19/2015 05:17 PM, Maxime Ripard wrote: On Fri, Aug 07, 2015 at 05:22:34PM +0200, Hans de Goede wrote: We've everything we need to support the gmac on Colombus, turn it on. Signed-off-by: Hans de Goede I recall that the phy was powered by one of the AXP221 regulators, does it require some additional stuff (like a recent u-boot), or does it just work and my memory is bad :) ? I think it just works, it MAY be connected to aldo1 but according to the git history for the u-boot defconfig that one is used for wifi not for the gmac, and we do not enable any other "spare" regulators in the u-boot config. I do not have any schematics, so no way to say for sure. I can confirm that the GMAC work fine with the latest u-boot master. Looking in the history we've always enabled ALDO1 on the Colombus in upstream u-boot, so this should all just work. Regards, Hans -- To unsubscribe from this list: send the line "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 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On 08/20/2015 08:18 AM, Vinod Koul wrote: > On Thu, Aug 20, 2015 at 11:41:33AM +0530, punnaiah choudary kalluri wrote: +- interrupts: Should contain DMA channel interrupt >>> channel interrupt or interrupts, former says it is plural >> >> ZynqMP DMA has single interrupt for each channel So, that is the reason >> i have explicitly mentioned it as interrupt ( not interrupts). >> >> Please let me know if you still want it to be plural. > > The example had multiple values so plural sounds right > I expect you are talking about this "interrupts = <0 117 4>;" It is 3 cells format used on ARM based on gic spec which is on SPI interrupt 117 active high level-sensitive Documentation/devicetree/bindings/arm/gic.txt Thanks, Michal -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On Thu, Aug 20, 2015 at 11:41:33AM +0530, punnaiah choudary kalluri wrote: > >> +- interrupts: Should contain DMA channel interrupt > > channel interrupt or interrupts, former says it is plural > > ZynqMP DMA has single interrupt for each channel So, that is the reason > i have explicitly mentioned it as interrupt ( not interrupts). > > Please let me know if you still want it to be plural. The example had multiple values so plural sounds right -- ~Vinod -- To unsubscribe from this list: send the line "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 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On Thu, Aug 20, 2015 at 11:22 AM, Vinod Koul wrote: > On Thu, Aug 06, 2015 at 08:49:32AM +0530, Punnaiah Choudary Kalluri wrote: >> Device-tree binding documentation for Xilinx zynqmp dma engine used in >> Zynq UltraScale+ MPSoC. >> >> Signed-off-by: Punnaiah Choudary Kalluri >> --- >> Changes in v4: >> - None >> Changes in v3: >> - None >> Changes in v2: >> - None >> --- >> .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt | 61 >> >> 1 files changed, 61 insertions(+), 0 deletions(-) >> create mode 100644 >> Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt >> >> diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt >> b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt >> new file mode 100644 >> index 000..e4f92b9 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt >> @@ -0,0 +1,61 @@ >> +Xilinx ZynqMP DMA engine, it does support memory to memory transfers, >> +memory to device and device to memory transfers. It also has flow >> +control and rate control support for slave/peripheral dma access. >> + >> +Required properties: >> +- compatible: Should be "xlnx,zynqmp-dma-1.0" >> +- #dma-cells: Should be <1>, a single cell holding a line request number >> +- reg: Memory map for module access >> +- interrupt-parent: Interrupt controller the interrupt is routed through >> +- interrupts: Should contain DMA channel interrupt > channel interrupt or interrupts, former says it is plural ZynqMP DMA has single interrupt for each channel So, that is the reason i have explicitly mentioned it as interrupt ( not interrupts). Please let me know if you still want it to be plural. Regards, Punnaiah > > -- > ~Vinod > -- To unsubscribe from this list: send the line "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 12/14] drm: bridge/analogix_dp: expand the delay time for hpd detect
On 2015. 8. 19., at PM 11:52, Yakir Yang wrote: > > Some edp screen with no hpd signal would need some delay time > to ensure that screen would be ready for work, so we can expand > the delay time in hpd detect function, it works prefectly on my > rk3288 sdk board. Then, this delay has a dependency on the "rk3288 sdk" board. Also, if the delay time is expanded, the booting time of some Exybos boards will be increased unnecessarily. :-( So, please add new DT property such as 'hpd-delay' that can be added to board DT files. If there is not that DT property in DT files, the default value '10' will written to a variable such as 'unsigned int hpd_delay'. If there is the DT property in DT files, the delay value will written to the variable when parsing DT values and will be used in analogix_dp_detect_hpd(). What I want to say is that there should not be harmful effect on the existing Exynos boards, due to unrelated reasons. Best regards, Jingoo Han > Signed-off-by: Yakir Yang > --- > Changes in v3: None > Changes in v2: None > > drivers/gpu/drm/bridge/analogix_dp_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c > b/drivers/gpu/drm/bridge/analogix_dp_core.c > index 99870f7..75dd44a 100644 > --- a/drivers/gpu/drm/bridge/analogix_dp_core.c > +++ b/drivers/gpu/drm/bridge/analogix_dp_core.c > @@ -68,7 +68,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device > *dp) >return 0; > >timeout_loop++; > -usleep_range(10, 11); > +usleep_range(100, 110); >} > >/* > -- > 1.9.1 > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] dma: Add Xilinx zynqmp dma engine driver support
On Thu, Aug 06, 2015 at 08:49:33AM +0530, Punnaiah Choudary Kalluri wrote:
> + list_for_each_entry_safe(desc, next, &chan->done_list, node) {
> + dma_async_tx_callback callback;
> + void *callback_param;
> +
> + list_del(&desc->node);
> +
> + callback = desc->async_tx.callback;
> + callback_param = desc->async_tx.callback_param;
> + if (callback) {
> + if (in_interrupt())
> + spin_unlock_bh(&chan->lock);
> + else
> + spin_unlock(&chan->lock);
This looks bad!
Why would callback be called from different context. It should only be
invoked from your tasklet
> +static int zynqmp_dma_device_terminate_all(struct dma_chan *dchan)
> +{
> + struct zynqmp_dma_chan *chan = to_chan(dchan);
> +
> + spin_lock_bh(&chan->lock);
> + zynqmp_dma_reset(chan);
> + spin_unlock_bh(&chan->lock);
No descriptor cleanup
> +static void zynqmp_dma_chan_remove(struct zynqmp_dma_chan *chan)
> +{
> + if (!chan)
> + return;
> +
> + devm_free_irq(chan->zdev->dev, chan->irq, chan);
> + tasklet_kill(&chan->tasklet);
> + list_del(&chan->common.device_node);
not deregistering with dmaengine?
> + zdev->chan = chan;
> + tasklet_init(&chan->tasklet, zynqmp_dma_do_tasklet, (ulong)chan);
> + spin_lock_init(&chan->lock);
> + INIT_LIST_HEAD(&chan->active_list);
> + INIT_LIST_HEAD(&chan->pending_list);
> + INIT_LIST_HEAD(&chan->done_list);
> + INIT_LIST_HEAD(&chan->free_list);
You can simmplify this by using vchan framework!
> +MODULE_AUTHOR("Xilinx, Inc.");
> +MODULE_DESCRIPTION("Xilinx ZynqMP DMA driver");
> +MODULE_LICENSE("GPL");
No alias, how did it get loaded?
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver
On 2015. 8. 20., at PM 1:29, Archit Taneja wrote: > > Hi, > >> On 08/19/2015 08:18 PM, Yakir Yang wrote: >> >> Hi all, >>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller >> share the same IP, so a lot of parts can be re-used. I split the common >> code into bridge directory, then rk3288 and exynos only need to keep >> some platform code. Cause I can't find the exact IP name of exynos dp >> controller, so I decide to name dp core driver with "analogix" which I >> find in rk3288 eDP TRM ;) >> >> Beyond that, there are three light registers setting differents bewteen >> exynos and rk3288. >> 1. RK3288 have five special pll resigters which not indicata in exynos >>dp controller. >> 2. The address of DP_PHY_PD(dp phy power manager register) are different >>between rk3288 and exynos. >> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug >>register). >> >> I have verified this series on two kinds of rockchip platform board, one >> is rk3288 sdk board which connect with a 2K display port monitor, the other >> is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2", >> both of them works rightlly. >> >> I haven't verified the dp function on samsung platform, cause I haven't got >> exynos boards. I can only ensure that there are no build error on samsung >> platform, wish some samsung guys help to test. ;) >> >> Thanks, >> - Yakir >> >> Changes in v3: >> - Take Thierry Reding suggest, move exynos's video_timing code >> to analogix_dp-exynos platform driver, add get_modes method >> to struct analogix_dp_plat_data. >> - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*". >> - Take Thierry Reding suggest, dynamic parse video timing info from >> struct drm_display_mode and struct drm_display_info. >> - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to >> the DT property value directly, but we can take those as hardware limite. >> For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane, >> so DT property would like "link-rate = 0x0a" "lane-count = 4". >> - Take Heiko suggest, add devicetree binding documents. >> - Take Thierry Reding suggest, remove sync pol & colorimetry properies >> from the new analogix dp driver devicetree binding. >> - Update the exist exynos dtsi file with the latest DP DT properies. >> - Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip >> dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp >> core driver which name to "dp", and leave "pclk_edp" to rockchip dp >> platform >> driver which name to "pclk". >> - Take Heiko suggest, add devicetree binding document. >> - Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote >> point to get panel node. >> - Add the new function point analogix_dp_platdata.get_modes init. >> - Take Heiko suggest, add rockchip dp phy driver, >> collect the phy clocks and power control. >> - Add "analogix,need-force-hpd" to indicate whether driver need foce >> hpd when hpd detect failed. >> - move dp hpd detect to connector detect function. >> - Add edid modes parse support >> >> Changes in v2: >> - Take Joe Preches advise, improved commit message more readable, and >> avoid using some uncommon style like bellow: >> - retval = exynos_dp_read_bytes_from_i2c(... >>...) >> + retval = >> + exynos_dp_read_bytes_from_i2c(..); >> - Take Jingoo Han suggest, just remove my name from author list. >> - Take Jingoo Han suggest, remove new copyright >> - Fix compiled failed dut to analogix_dp_device misspell >> - Take Heiko suggest, get panel node with remote-endpoint method, >> and create devicetree binding for driver. >> - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m", >> leave those clock to rockchip dp phy driver. >> - Add GNU license v2 declared and samsung copyright >> - Fix compile failed dut to phy_pd_addr variable misspell error >> >> Yakir Yang (14): >> drm: exynos/dp: fix code style >> drm: exynos/dp: convert to drm bridge mode >> drm: bridge: analogix_dp: split exynos dp driver to bridge dir >> drm: bridge/analogix_dp: dynamic parse sync_pol & interlace & >> colorimetry >> drm: bridge/analogix_dp: fix link_rate & lane_count bug >> Documentation: drm/bridge: add document for analogix_dp >> drm: rockchip/dp: add rockchip platform dp driver >> phy: Add driver for rockchip Display Port PHY >> drm: bridge/analogix_dp: add platform device type support >> drm: bridge: analogix_dp: add some rk3288 special registers setting >> drm: bridge: analogix_dp: try force hpd after plug in lookup failed >> drm: bridge/analogix_dp: expand the delay time for hpd detect >> drm: bridge/analogix_dp: move hpd detect to connector detect function >> drm: bridge/analogix_dp: add edid modes parse in get_modes method >> >> .../devicetree/bindings/drm/bridge/analogix_dp.txt | 73 + >
Re: [PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On Thu, Aug 06, 2015 at 08:49:32AM +0530, Punnaiah Choudary Kalluri wrote: > Device-tree binding documentation for Xilinx zynqmp dma engine used in > Zynq UltraScale+ MPSoC. > > Signed-off-by: Punnaiah Choudary Kalluri > --- > Changes in v4: > - None > Changes in v3: > - None > Changes in v2: > - None > --- > .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt | 61 > > 1 files changed, 61 insertions(+), 0 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt > > diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt > b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt > new file mode 100644 > index 000..e4f92b9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt > @@ -0,0 +1,61 @@ > +Xilinx ZynqMP DMA engine, it does support memory to memory transfers, > +memory to device and device to memory transfers. It also has flow > +control and rate control support for slave/peripheral dma access. > + > +Required properties: > +- compatible: Should be "xlnx,zynqmp-dma-1.0" > +- #dma-cells: Should be <1>, a single cell holding a line request number > +- reg: Memory map for module access > +- interrupt-parent: Interrupt controller the interrupt is routed through > +- interrupts: Should contain DMA channel interrupt channel interrupt or interrupts, former says it is plural -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] mailbox: Hi6220: add mailbox driver
On 2015/8/20 10:53, Leo Yan wrote:
Add driver for Hi6220 mailbox, the mailbox communicates with MCU; for
sending data, it can support two methods for low level implementation:
one is to use interrupt as acknowledge, another is automatic mode which
without any acknowledge. These two methods have been supported in the
driver. For receiving data, it will depend on the interrupt to notify
the channel has incoming message; enhance rx channel's message queue,
which is based on the code in drivers/mailbox/omap-mailbox.c.
Now mailbox driver is used to send message to MCU to control dynamic
voltage and frequency scaling for CPU, GPU and DDR.
Signed-off-by: Leo Yan
---
drivers/mailbox/Kconfig | 8 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/hi6220-mailbox.c | 519 +++
3 files changed, 529 insertions(+)
create mode 100644 drivers/mailbox/hi6220-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index e269f08..21b71dd 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -70,4 +70,12 @@ config BCM2835_MBOX
the services of the Videocore. Say Y here if you want to use the
BCM2835 Mailbox.
+config HI6220_MBOX
+ tristate "Hi6220 Mailbox"
+ depends on ARCH_HISI
+ help
+ An implementation of the hi6220 mailbox. It is used to send message
+ between application processors and MCU. Say Y here if you want to
build
+ the Hi6220 mailbox controller driver.
+
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 8e6d822..4ba9f5f 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -13,3 +13,5 @@ obj-$(CONFIG_PCC) += pcc.o
obj-$(CONFIG_ALTERA_MBOX) += mailbox-altera.o
obj-$(CONFIG_BCM2835_MBOX)+= bcm2835-mailbox.o
+
+obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o
diff --git a/drivers/mailbox/hi6220-mailbox.c b/drivers/mailbox/hi6220-mailbox.c
new file mode 100644
index 000..8f63d0d
--- /dev/null
+++ b/drivers/mailbox/hi6220-mailbox.c
@@ -0,0 +1,519 @@
+/*
+ * Hisilicon's Hi6220 mailbox driver
+ *
+ * RX channel's message queue is based on the code written in
+ * drivers/mailbox/omap-mailbox.c.
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ * Copyright (c) 2015 Linaro Limited.
+ *
+ * Author: Leo Yan
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HI6220_MBOX_CHAN_MAX 32
+#define HI6220_MBOX_CHAN_NUM 2
+#define HI6220_MBOX_CHAN_SLOT_SIZE 64
+
+#define HI6220_MBOX_RX 0x0
+#define HI6220_MBOX_TX 0x1
+
+/* Mailbox message length: 32 bytes */
+#define HI6220_MBOX_MSG_LEN32
+
+/* Mailbox kfifo size */
+#define HI6220_MBOX_MSG_FIFO_SIZE 512
+
+/* Status & Mode Register */
+#define HI6220_MBOX_MODE_REG 0x0
+
+#define HI6220_MBOX_STATUS_MASK(0xF << 4)
+#define HI6220_MBOX_STATUS_IDLE(0x1 << 4)
+#define HI6220_MBOX_STATUS_TX (0x2 << 4)
+#define HI6220_MBOX_STATUS_RX (0x4 << 4)
+#define HI6220_MBOX_STATUS_ACK (0x8 << 4)
+#define HI6220_MBOX_ACK_CONFIG_MASK(0x1 << 0)
+#define HI6220_MBOX_ACK_AUTOMATIC (0x1 << 0)
+#define HI6220_MBOX_ACK_IRQ(0x0 << 0)
+
+/* Data Registers */
+#define HI6220_MBOX_DATA_REG(i)(0x4 + (i << 2))
+
+/* ACPU Interrupt Register */
+#define HI6220_MBOX_ACPU_INT_RAW_REG 0x400
+#define HI6220_MBOX_ACPU_INT_MSK_REG 0x404
+#define HI6220_MBOX_ACPU_INT_STAT_REG 0x408
+#define HI6220_MBOX_ACPU_INT_CLR_REG 0x40c
+#define HI6220_MBOX_ACPU_INT_ENA_REG 0x500
+#define HI6220_MBOX_ACPU_INT_DIS_REG 0x504
+
+/* MCU Interrupt Register */
+#define HI6220_MBOX_MCU_INT_RAW_REG0x420
+
+/* Core Id */
+#define HI6220_CORE_ACPU 0x0
+#define HI6220_CORE_MCU0x2
+
+struct hi6220_mbox_queue {
+ struct kfifo fifo;
+ struct work_struct work;
+ struct mbox_chan *chan;
+ bool full;
+};
+
+struct hi6220_mbox_chan {
+
+ /*
+* Description for channel's hardware info:
+* - direction;
+* - peer core id for communication;
+* - local irq vector or number;
+* - remoted irq vector or number for peer core;
+*/
+ unsigned int dir;
+ unsigned int peer_core;
+ unsigned int remote_irq;
+ unsigned int local_irq;
+
+ /*
+* Slot addre
Re: [PATCH v1 3/4] Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver
On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
> + nents = sg_nents(req->src);
> + sg_count = dma_map_sg(dev, req->src, nents, DMA_TO_DEVICE);
> + if (!sg_count) {
> + dev_err(dev, "Failed to map src sg");
> + return -ENOMEM;
mapping error shouldn't be no mem error
> + }
> +
> + if (sg_count > XGENE_DMA_MAX_FLYBY_SRC_CNT) {
> + dev_err(dev, "Unsupported src sg len\n");
would be worth printing length
> + goto err;
> + }
> +
> + flags = DMA_CTRL_ACK;
why ACK?
> +
> + tx = dchan->device->device_prep_dma_crc32c(dchan, req->src,
> +req->nbytes,
> +reqctx->seed,
> +req->result,
> +flags);
We should add helper for this
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 2/4] dmaengine: xgene-dma: Add support for CRC32C calculation via DMA engine
On Thu, Jul 30, 2015 at 05:41:06PM +0530, Rameshwar Prasad Sahu wrote:
> + /* Invalidate unused source address field */
> + for (; i < 4; i++)
> + xgene_dma_invalidate_buffer(xgene_dma_lookup_ext8(desc2, i));
> +
> + /* Check whether requested buffer processed */
> + if (nbytes) {
> + chan_err(chan, "Src count crossed maximum limit\n");
> + return -EINVAL;
no cleanup ?
> +struct dma_async_tx_descriptor *xgene_dma_prep_flyby(
> + struct xgene_dma_chan *chan, struct scatterlist *src_sg,
> + size_t len, u32 seed, u8 *result, unsigned long flags, u8 opcode)
please fix style here
> +struct dma_async_tx_descriptor *xgene_dma_prep_crc32c(
> + struct dma_chan *dchan, struct scatterlist *src_sg,
> + size_t len, u32 seed, u8 *result, unsigned long flags)
here too
> @@ -1309,8 +1512,13 @@ static void xgene_dma_setup_ring(struct xgene_dma_ring
> *ring)
> ring->pdma->csr_ring + XGENE_DMA_RING_ID);
>
> /* Set DMA ring buffer */
> - iowrite32(XGENE_DMA_RING_ID_BUF_SETUP(ring->num),
> - ring->pdma->csr_ring + XGENE_DMA_RING_ID_BUF);
> + ring_id_buf = XGENE_DMA_RING_ID_BUF_SETUP(ring->num);
> +
> + if (ring->is_bufpool)
> + ring_id_buf |= XGENE_DMA_RING_IS_BUFPOOL;
> +
> + iowrite32(ring_id_buf, ring->pdma->csr_ring +
> + XGENE_DMA_RING_ID_BUF);
pls fix style here
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
On Tuesday, August 18, 2015 at 10:18:33 PM, vikas wrote: > Hi, > > On 08/18/2015 12:03 PM, Graham Moore wrote: > > Hi all, > > > > On 08/18/2015 12:48 AM, Vikas MANOCHA wrote: > > > > [...] > > > > +Required properties: > > +- compatible : Should be "cdns,qspi-nor". > > +- reg : Contains two entries, each of which is a tuple consisting of > > a +physical address and length. The first entry is the address > > and +length of the controller register set. The second entry is > > the +address and length of the QSPI Controller data area. > > "Controller data area", i think it means mapped NOR Flash address ? > >>> > >>> Probably ; Graham ? > >>> > If yes, it would be more clear with "Physical base address & size of > NOR Flash". > >>> > >>> This is the Direct mode thing, correct ? We don't support this, so I > >>> think we should drop this bit altogether and keep only one single > >>> address in this field. > >> > >> No it's not. > > > > It's the location of the SRAM fifo. Also direct mode location I think, > > if that were ever used. > > Hmm...It is the base address of NOR flash. SRAM is not memory mapped. Huh ? I am inclined to trust Graham more -- I have seen memory mapped SRAM, but I have yet to see memory mapped SPI NOR. Also, the driver code clearly uses that area in a way one would use a memory mapped SRAM with FIFO on the other side. I think the above description is pretty much OK. > > The size is determined by a configuration parameter during system > > design. On Altera Cyclone5 the size is really big compared to SRAM > > fifo. I don't know why, maybe some hw engineer thought it would be > > better to have a large size in case direct mode was used. > > my comment is about second parameter of property "reg" which is NOR flash > address, so above explanation does not make sense for it. > Also in direct mode, sram does not come into play. This is absolutelly not a SPI NOR address. Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/4] dmaengine: Add support for new feature CRC32C
On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote: > This patch adds support for new feature CRC32C calculation in > dmaengine framework. Looks okay can you please update Documentation also -- ~Vinod -- To unsubscribe from this list: send the line "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 08/14] phy: Add driver for rockchip Display Port PHY
Hi,
On Wednesday 19 August 2015 08:21 PM, Yakir Yang wrote:
> Signed-off-by: Yakir Yang
where's the commit message?
> ---
> Changes in v3:
> - Take Heiko suggest, add rockchip dp phy driver,
> collect the phy clocks and power control.
>
> Changes in v2: None
>
> .../devicetree/bindings/phy/rockchip-dp-phy.txt| 26 +++
> drivers/phy/Kconfig| 7 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-rockchip-dp.c | 185
> +
> 4 files changed, 219 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> create mode 100644 drivers/phy/phy-rockchip-dp.c
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> new file mode 100644
> index 000..5de1088
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> @@ -0,0 +1,26 @@
> +Rockchip Soc Seroes Display Port PHY
> +
> +
> +Required properties:
> +- compatible : should be one of the following supported values:
> + - "rockchip.rk3288-dp-phy"
> +
> +- reg : a list of registers used by phy driver
> +- clocks: from common clock binding: handle to dp clock.
> + of memory mapped region.
> +- clock-names: from common clock binding:
> + Required elements: "sclk_dp" "sclk_dp_24m"
> +
> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> +- #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Example:
> +
> +edp_phy: phy@ff770274 {
> + compatilble = "rockchip,rk3288-dp-phy";
> + reg = <0xff770274 4>;
> + rockchip,grf = <&grf>;
> + clocks = <&cru SCLK_EDP_24M>;
> + clock-names = "24m";
> + #phy-cells = <0>;
> +}
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 6b8dd16..da00440 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -297,6 +297,13 @@ config PHY_ROCKCHIP_USB
> help
> Enable this to support the Rockchip USB 2.0 PHY.
>
> +config PHY_ROCKCHIP_DP
> + tristate "Rockchip Display Port PHY Driver"
> + depends on ARCH_ROCKCHIP && OF
> + select GENERIC_PHY
> + help
> + Enable this to support the Rockchip Display Port PHY.
> +
> config PHY_ST_SPEAR1310_MIPHY
> tristate "ST SPEAR1310-MIPHY driver"
> select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index f344e1b..35e3ce6 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -33,6 +33,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) +=
> phy-s5pv210-usb2.o
> obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
> obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += phy-qcom-apq8064-sata.o
> obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
> obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) += phy-qcom-ipq806x-sata.o
> obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
> obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..4759111
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,185 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define GRF_SOC_CON12 0x0274
> +#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
> +
> +#define DP_PHY_SIDDQ_WRITE_EN BIT(21)
> +#define DP_PHY_SIDDQ_ON 0
> +#define DP_PHY_SIDDQ_OFFBIT(5)
> +
> +struct rockchip_dp_phy {
> + struct device *dev;
> + struct regmap *grf;
> + void __iomem *regs;
> + struct clk *phy_24m;
> +};
> +
> +static int rockchip_dp_phy_clk_enable(struct rockchip_dp_phy *dp)
> +{
> + int ret = 0;
> +
> + ret = clk_set_rate(dp->phy_24m, 2400);
> + if (ret < 0) {
> + dev_err(dp->dev, "cannot set clock phy_24m %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(dp->phy_24m);
> + if (ret < 0) {
> + dev_err(dp->dev, "cannot enable clock phy_24m %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int rockchip_dp_phy_clk_disable(struct rockchip_dp_phy *dp)
> +{
> + clk_disable_unprepare(dp->phy_24m);
> +
> + return 0;
> +}
> +
> +static int rockchip_set_phy_state(struct phy *phy, bool enable)
> +{
> + struct rockchip_dp_phy *dp = phy_get_
Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver
Hi, On 08/19/2015 08:18 PM, Yakir Yang wrote: Hi all, The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller share the same IP, so a lot of parts can be re-used. I split the common code into bridge directory, then rk3288 and exynos only need to keep some platform code. Cause I can't find the exact IP name of exynos dp controller, so I decide to name dp core driver with "analogix" which I find in rk3288 eDP TRM ;) Beyond that, there are three light registers setting differents bewteen exynos and rk3288. 1. RK3288 have five special pll resigters which not indicata in exynos dp controller. 2. The address of DP_PHY_PD(dp phy power manager register) are different between rk3288 and exynos. 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug register). I have verified this series on two kinds of rockchip platform board, one is rk3288 sdk board which connect with a 2K display port monitor, the other is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2", both of them works rightlly. I haven't verified the dp function on samsung platform, cause I haven't got exynos boards. I can only ensure that there are no build error on samsung platform, wish some samsung guys help to test. ;) Thanks, - Yakir Changes in v3: - Take Thierry Reding suggest, move exynos's video_timing code to analogix_dp-exynos platform driver, add get_modes method to struct analogix_dp_plat_data. - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*". - Take Thierry Reding suggest, dynamic parse video timing info from struct drm_display_mode and struct drm_display_info. - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to the DT property value directly, but we can take those as hardware limite. For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would like "link-rate = 0x0a" "lane-count = 4". - Take Heiko suggest, add devicetree binding documents. - Take Thierry Reding suggest, remove sync pol & colorimetry properies from the new analogix dp driver devicetree binding. - Update the exist exynos dtsi file with the latest DP DT properies. - Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp core driver which name to "dp", and leave "pclk_edp" to rockchip dp platform driver which name to "pclk". - Take Heiko suggest, add devicetree binding document. - Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote point to get panel node. - Add the new function point analogix_dp_platdata.get_modes init. - Take Heiko suggest, add rockchip dp phy driver, collect the phy clocks and power control. - Add "analogix,need-force-hpd" to indicate whether driver need foce hpd when hpd detect failed. - move dp hpd detect to connector detect function. - Add edid modes parse support Changes in v2: - Take Joe Preches advise, improved commit message more readable, and avoid using some uncommon style like bellow: - retval = exynos_dp_read_bytes_from_i2c(... ...) + retval = + exynos_dp_read_bytes_from_i2c(..); - Take Jingoo Han suggest, just remove my name from author list. - Take Jingoo Han suggest, remove new copyright - Fix compiled failed dut to analogix_dp_device misspell - Take Heiko suggest, get panel node with remote-endpoint method, and create devicetree binding for driver. - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m", leave those clock to rockchip dp phy driver. - Add GNU license v2 declared and samsung copyright - Fix compile failed dut to phy_pd_addr variable misspell error Yakir Yang (14): drm: exynos/dp: fix code style drm: exynos/dp: convert to drm bridge mode drm: bridge: analogix_dp: split exynos dp driver to bridge dir drm: bridge/analogix_dp: dynamic parse sync_pol & interlace & colorimetry drm: bridge/analogix_dp: fix link_rate & lane_count bug Documentation: drm/bridge: add document for analogix_dp drm: rockchip/dp: add rockchip platform dp driver phy: Add driver for rockchip Display Port PHY drm: bridge/analogix_dp: add platform device type support drm: bridge: analogix_dp: add some rk3288 special registers setting drm: bridge: analogix_dp: try force hpd after plug in lookup failed drm: bridge/analogix_dp: expand the delay time for hpd detect drm: bridge/analogix_dp: move hpd detect to connector detect function drm: bridge/analogix_dp: add edid modes parse in get_modes method .../devicetree/bindings/drm/bridge/analogix_dp.txt | 73 + .../devicetree/bindings/phy/rockchip-dp-phy.txt| 26 + .../bindings/video/analogix_dp-rockchip.txt| 83 ++ .../devicetree/bindings/video/exynos_dp.txt| 51 +- arch/arm/boot/dts/exynos5250-arndale.dts | 10 +- arch/arm/boot/dts/exynos5250-smdk5250.dt
[PATCH v2 2/3] mailbox: Hi6220: add mailbox driver
Add driver for Hi6220 mailbox, the mailbox communicates with MCU; for
sending data, it can support two methods for low level implementation:
one is to use interrupt as acknowledge, another is automatic mode which
without any acknowledge. These two methods have been supported in the
driver. For receiving data, it will depend on the interrupt to notify
the channel has incoming message; enhance rx channel's message queue,
which is based on the code in drivers/mailbox/omap-mailbox.c.
Now mailbox driver is used to send message to MCU to control dynamic
voltage and frequency scaling for CPU, GPU and DDR.
Signed-off-by: Leo Yan
---
drivers/mailbox/Kconfig | 8 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/hi6220-mailbox.c | 519 +++
3 files changed, 529 insertions(+)
create mode 100644 drivers/mailbox/hi6220-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index e269f08..21b71dd 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -70,4 +70,12 @@ config BCM2835_MBOX
the services of the Videocore. Say Y here if you want to use the
BCM2835 Mailbox.
+config HI6220_MBOX
+ tristate "Hi6220 Mailbox"
+ depends on ARCH_HISI
+ help
+ An implementation of the hi6220 mailbox. It is used to send message
+ between application processors and MCU. Say Y here if you want to
build
+ the Hi6220 mailbox controller driver.
+
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 8e6d822..4ba9f5f 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -13,3 +13,5 @@ obj-$(CONFIG_PCC) += pcc.o
obj-$(CONFIG_ALTERA_MBOX) += mailbox-altera.o
obj-$(CONFIG_BCM2835_MBOX) += bcm2835-mailbox.o
+
+obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o
diff --git a/drivers/mailbox/hi6220-mailbox.c b/drivers/mailbox/hi6220-mailbox.c
new file mode 100644
index 000..8f63d0d
--- /dev/null
+++ b/drivers/mailbox/hi6220-mailbox.c
@@ -0,0 +1,519 @@
+/*
+ * Hisilicon's Hi6220 mailbox driver
+ *
+ * RX channel's message queue is based on the code written in
+ * drivers/mailbox/omap-mailbox.c.
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ * Copyright (c) 2015 Linaro Limited.
+ *
+ * Author: Leo Yan
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HI6220_MBOX_CHAN_MAX 32
+#define HI6220_MBOX_CHAN_NUM 2
+#define HI6220_MBOX_CHAN_SLOT_SIZE 64
+
+#define HI6220_MBOX_RX 0x0
+#define HI6220_MBOX_TX 0x1
+
+/* Mailbox message length: 32 bytes */
+#define HI6220_MBOX_MSG_LEN32
+
+/* Mailbox kfifo size */
+#define HI6220_MBOX_MSG_FIFO_SIZE 512
+
+/* Status & Mode Register */
+#define HI6220_MBOX_MODE_REG 0x0
+
+#define HI6220_MBOX_STATUS_MASK(0xF << 4)
+#define HI6220_MBOX_STATUS_IDLE(0x1 << 4)
+#define HI6220_MBOX_STATUS_TX (0x2 << 4)
+#define HI6220_MBOX_STATUS_RX (0x4 << 4)
+#define HI6220_MBOX_STATUS_ACK (0x8 << 4)
+#define HI6220_MBOX_ACK_CONFIG_MASK(0x1 << 0)
+#define HI6220_MBOX_ACK_AUTOMATIC (0x1 << 0)
+#define HI6220_MBOX_ACK_IRQ(0x0 << 0)
+
+/* Data Registers */
+#define HI6220_MBOX_DATA_REG(i)(0x4 + (i << 2))
+
+/* ACPU Interrupt Register */
+#define HI6220_MBOX_ACPU_INT_RAW_REG 0x400
+#define HI6220_MBOX_ACPU_INT_MSK_REG 0x404
+#define HI6220_MBOX_ACPU_INT_STAT_REG 0x408
+#define HI6220_MBOX_ACPU_INT_CLR_REG 0x40c
+#define HI6220_MBOX_ACPU_INT_ENA_REG 0x500
+#define HI6220_MBOX_ACPU_INT_DIS_REG 0x504
+
+/* MCU Interrupt Register */
+#define HI6220_MBOX_MCU_INT_RAW_REG0x420
+
+/* Core Id */
+#define HI6220_CORE_ACPU 0x0
+#define HI6220_CORE_MCU0x2
+
+struct hi6220_mbox_queue {
+ struct kfifo fifo;
+ struct work_struct work;
+ struct mbox_chan *chan;
+ bool full;
+};
+
+struct hi6220_mbox_chan {
+
+ /*
+* Description for channel's hardware info:
+* - direction;
+* - peer core id for communication;
+* - local irq vector or number;
+* - remoted irq vector or number for peer core;
+*/
+ unsigned int dir;
+ unsigned int peer_core;
+ unsigned int remote_irq;
+ unsigned int local_irq;
+
+ /*
+* Slot address is cached value derived from index
+
[PATCH v2 0/3] mailbox: hisilicon: add Hi6220 mailbox driver
Hi6220 mailbox supports up to 32 channels. Each channel is unidirectional with a maximum message size of 8 words. I/O is performed using register access (there is no DMA) and the cell raises an interrupt when messages are received. This patch series is to implement Hi6220 mailbox driver. It registers two channels into framework for communication with MCU, one is tx channel and another is rx channel. Now mailbox driver is used to send message to MCU to control dynamic voltage and frequency scaling for CPU, GPU and DDR. Changes from v1: * Correct lock usage for SMP scenario Changes from RFC: * According to Jassi's review, totally remove the abstract common driver layer and only commit driver dedicated for Hi6220 * According to Paul Bolle's review, fix typo issue for Kconfig and remove unnecessary dependency with OF and fix minor for mailbox driver * Refine a little for dts nodes Leo Yan (3): dt-bindings: mailbox: Document Hi6220 mailbox driver mailbox: Hi6220: add mailbox driver arm64: dts: add Hi6220 mailbox node .../bindings/mailbox/hisilicon,hi6220-mailbox.txt | 57 +++ arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 20 +- arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8 + drivers/mailbox/Kconfig| 8 + drivers/mailbox/Makefile | 2 + drivers/mailbox/hi6220-mailbox.c | 519 + 6 files changed, 611 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt create mode 100644 drivers/mailbox/hi6220-mailbox.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] dt-bindings: mailbox: Document Hi6220 mailbox driver
Document the new compatible for Hisilicon Hi6220 mailbox driver.
Signed-off-by: Leo Yan
---
.../bindings/mailbox/hisilicon,hi6220-mailbox.txt | 57 ++
1 file changed, 57 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
diff --git
a/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
new file mode 100644
index 000..3dfb0b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
@@ -0,0 +1,57 @@
+Hisilicon Hi6220 Mailbox Driver
+===
+
+Hisilicon Hi6220 mailbox supports up to 32 channels. Each channel
+is unidirectional with a maximum message size of 8 words. I/O is
+performed using register access (there is no DMA) and the cell
+raises an interrupt when messages are received.
+
+Mailbox Device Node:
+
+
+Required properties:
+
+- compatible: Shall be "hisilicon,hi6220-mbox"
+- reg: Contains the mailbox register address range (base
+ address and length); the first item is for IPC
+ registers, the second item is shared buffer for
+ slots.
+- #mbox-cells Common mailbox binding property to identify the number
+ of cells required for the mailbox specifier. Should be
1.
+- interrupts: Contains the interrupt information for the mailbox
+ device. The format is dependent on which interrupt
+ controller the SoCs use.
+
+Example:
+
+
+ mailbox: mailbox@F751 {
+ #mbox-cells = <1>;
+ compatible = "hisilicon,hi6220-mbox";
+ reg = <0x0 0xF751 0x0 0x1000>, /* IPC_S */
+ <0x0 0x06DFF800 0x0 0x0800>; /* Mailbox */
+ interrupt-parent = <&gic>;
+ interrupts = <0 94 4>;
+ };
+
+
+Mailbox client
+===
+
+"mboxes" and the optional "mbox-names" (please see
+Documentation/devicetree/bindings/mailbox/mailbox.txt for details). Each value
+of the mboxes property should contain a phandle to the mailbox controller
+device node and second argument is the channel index. It must be 0 (hardware
+support only one channel). The equivalent "mbox-names" property value can be
+used to give a name to the communication channel to be used by the client user.
+
+Example:
+
+
+ stub_clock: stub_clock {
+ compatible = "hisilicon,hi6220-stub-clk";
+ hisilicon,hi6220-clk-sram = <&sram>;
+ #clock-cells = <1>;
+ mbox-names = "mbox-tx";
+ mboxes = <&mailbox 1>;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] arm64: dts: add Hi6220 mailbox node
On Hi6220, below memory regions in DDR have specific purpose:
0x05e0, - 0x05ef,: For MCU firmware using at runtime;
0x0740,f000 - 0x0740,: For MCU firmware's section;
0x06df,f000 - 0x06df,: For mailbox message data.
This patch reserves these memory regions and add device node for
mailbox in dts.
Signed-off-by: Leo Yan
---
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 20 +---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index e36a539..d5470d3 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -7,9 +7,6 @@
/dts-v1/;
-/*Reserved 1MB memory for MCU*/
-/memreserve/ 0x05e0 0x0010;
-
#include "hi6220.dtsi"
/ {
@@ -28,4 +25,21 @@
device_type = "memory";
reg = <0x0 0x0 0x0 0x4000>;
};
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ mcu-buf@05e0 {
+ no-map;
+ reg = <0x0 0x05e0 0x0 0x0010>, /* MCU firmware
buffer */
+ <0x0 0x0740f000 0x0 0x1000>; /* MCU firmware
section */
+ };
+
+ mbox-buf@06dff000 {
+ no-map;
+ reg = <0x0 0x06dff000 0x0 0x1000>; /* Mailbox
message buf */
+ };
+ };
};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..9ff25bc 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -167,5 +167,13 @@
clocks = <&ao_ctrl 36>, <&ao_ctrl 36>;
clock-names = "uartclk", "apb_pclk";
};
+
+ mailbox: mailbox@f751 {
+ #mbox-cells = <1>;
+ compatible = "hisilicon,hi6220-mbox";
+ reg = <0x0 0xf751 0x0 0x1000>, /* IPC_S */
+ <0x0 0x06dff800 0x0 0x0800>; /* Mailbox buffer */
+ interrupts = ;
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/8] ARM: sunxi: Add Reduced Serial Bus support
On Thu, Aug 20, 2015 at 12:32 AM, Mark Brown wrote: > On Wed, Aug 19, 2015 at 12:20:01PM +0800, Chen-Yu Tsai wrote: >> Hi everyone, >> >> This is my third attempt at adding support for Allwinner's Reduced >> Serial Bus (RSB), which is used to communicate with PMICs and other >> peripherals on their newer SoCs, such as the A23/A33/A80. > > This is flagged as something that is specific to the Allwinner SoCs. > Why add generic regmap support rather than just implement the regmap > reg_read() and reg_write() in a regmap in the controller driver? Are > there expected to be other controller drivers from other vendors? I don't expect there to be any other controller drivers. And it seems at least some of the devices are dual interface (I2C/RSB). Though I don't see how its connected to the generic regmap support. Regmap is for device drivers connected to the RSB bus, not the bus controller itself. That said, there are a few RSB mfd slave devices that need support, those being the later AXP series PMICs, and AC100/AC200 audio-codec/RTC chips. The current axp20x driver already uses i2c regmaps. I could throw all the RSB-related stuff together, presumably under drivers/soc/sunxi/rsb, though that doesn't help the fact that common regmap code would be better than scattering regmap_* in various mfd drivers. Regards ChenYu -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver
Hi Dave, On 08/19/2015 06:54 PM, Dave Airlie wrote: On 20 August 2015 at 00:48, Yakir Yang wrote: Hi all, The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller share the same IP, so a lot of parts can be re-used. I split the common code into bridge directory, then rk3288 and exynos only need to keep some platform code. Cause I can't find the exact IP name of exynos dp controller, so I decide to name dp core driver with "analogix" which I find in rk3288 eDP TRM ;) Beyond that, there are three light registers setting differents bewteen exynos and rk3288. 1. RK3288 have five special pll resigters which not indicata in exynos dp controller. 2. The address of DP_PHY_PD(dp phy power manager register) are different between rk3288 and exynos. 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug register). I have verified this series on two kinds of rockchip platform board, one is rk3288 sdk board which connect with a 2K display port monitor, the other is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2", both of them works rightlly. I haven't verified the dp function on samsung platform, cause I haven't got exynos boards. I can only ensure that there are no build error on samsung platform, wish some samsung guys help to test. ;) I'd like to pull this in, but it probably needs an ack from Samsung, Inki can you guys find some time to test this? Dave. Wow, thanks a lots :-) Still waiting for some reviews and acks. Best regards, - Yakir -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller
On Wed, Aug 19, 2015 at 07:44:10PM +0200, Lars-Peter Clausen wrote: > On 08/19/2015 07:12 PM, Vinod Koul wrote: > > On Tue, Jul 28, 2015 at 11:38:06AM +0200, Lars-Peter Clausen wrote: > >>> where is device side programming ? > >> > >> in the start_transfer() function. > > > > I must have missed that but still don't see it here, can you point me > > Oh you mean the DMA address for the device? It's a dedicated bus on the > device side, so there is no address to program on the device side. Yes but that was not very clear from the patch. Please document that, also the unidirectional feature of the channels here -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver
On 20 August 2015 at 00:48, Yakir Yang wrote: > > Hi all, >The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller > share the same IP, so a lot of parts can be re-used. I split the common > code into bridge directory, then rk3288 and exynos only need to keep > some platform code. Cause I can't find the exact IP name of exynos dp > controller, so I decide to name dp core driver with "analogix" which I > find in rk3288 eDP TRM ;) > > Beyond that, there are three light registers setting differents bewteen > exynos and rk3288. > 1. RK3288 have five special pll resigters which not indicata in exynos >dp controller. > 2. The address of DP_PHY_PD(dp phy power manager register) are different >between rk3288 and exynos. > 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug >register). > > I have verified this series on two kinds of rockchip platform board, one > is rk3288 sdk board which connect with a 2K display port monitor, the other > is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2", > both of them works rightlly. > > I haven't verified the dp function on samsung platform, cause I haven't got > exynos boards. I can only ensure that there are no build error on samsung > platform, wish some samsung guys help to test. ;) I'd like to pull this in, but it probably needs an ack from Samsung, Inki can you guys find some time to test this? Dave. -- To unsubscribe from this list: send the line "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/3] ARM: dts: rockchip: correct regulator power states for suspend
Hello Brian, On Thu, Aug 20, 2015 at 12:18 AM, Brian Norris wrote: > When getting translated from a downstream device tree that used slightly > different DT bindings, these regulators got labeled with the > "on-in-suspend" state, when they were actually supposed to be turned off > for S3 suspend. This was harmless, but not intentional, AFAICT. > > Let's turn them off to get the optimal power state. > > Signed-off-by: Brian Norris > Cc: Alexandru M Stan > Cc: Douglas Anderson > --- > New in v2. Tested jaq. > > arch/arm/boot/dts/rk3288-veyron-jerry.dts | 2 +- > arch/arm/boot/dts/rk3288-veyron-pinky.dts | 2 +- > arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi | 4 ++-- > 3 files changed, 4 insertions(+), 4 deletions(-) > Reviewed-by: Javier Martinez Canillas Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: dts: rockchip: correct regulator PM properties
Hello Brian, On Thu, Aug 20, 2015 at 12:18 AM, Brian Norris wrote: > This DTS file was submitted with non-upstream bindings. I happened > across this while reviewing the jaq DTS. > > Signed-off-by: Brian Norris > Cc: Alexandru M Stan > Cc: Douglas Anderson > --- > Did not test minnie > > v1 -> v2: > - use "off-in-suspend", as that's the equivalent to the downstream >'regulator-suspend-mem-disabled' > > arch/arm/boot/dts/rk3288-veyron-minnie.dts | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > Patch looks good to me. Reviewed-by: Javier Martinez Canillas Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: dts: rockchip: add veyron-jaq board
Hello Brian,
[...]
> +
> +&rk808 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_int_l &dvs_1 &dvs_2>;
> + dvs-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>,
> + <&gpio7 15 GPIO_ACTIVE_HIGH>;
I see the dvs-gpios DT property is documented in the downstream
ChromiumOS 3.18 tree [0] but I don't see it neither mentioned in
Documentation/devicetree/bindings/mfd/rk808.txt in mainline nor code
that parses it in the drivers/regulator/rk808-regulator.c driver.
So I think this should be removed and also the dvs_{1,2} pinctrl
lines. The rest of the patch looks good to me though so with these
removed feel free to add:
Reviewed-by: Javier Martinez Canillas
[0]:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/Documentation/devicetree/bindings/mfd/rk808.txt
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: dts: rockchip: add veyron-jaq board
On Wed, Aug 19, 2015 at 03:38:43PM -0700, Alexandru Stan wrote: > On Wed, Aug 19, 2015 at 3:18 PM, Brian Norris > wrote: > > > +++ b/Documentation/devicetree/bindings/arm/rockchip.txt > > ... > > > +- Google Jaq (Haier Chromebook 11): > > > Could you add s/)/ and more)/ similar to what Jerry has? This is jaq too: > http://sasthamarket.com/wp-content/uploads/2015/06/34.jpg Sure. I'll wait for any other comments on v2 before sending the next (and final?) version. Thanks, Brian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: shmobile: silk: add VIN0/ADV7180 DT support
Define the SILK board dependent part of the VIN0 device node.
Add the device node for Analog Devices ADV7180 video decoder to I2C1 bus.
Add the necessary subnodes to interconnect VIN0 and ADV7180 devices.
Based on the Henninger VIN0/ADV8170 device tree patch by myself.
Signed-off-by: Sergei Shtylyov
---
arch/arm/boot/dts/r8a7794-silk.dts | 35 +++
1 file changed, 35 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7794-silk.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7794-silk.dts
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -104,6 +104,11 @@
renesas,groups = "qspi_ctrl", "qspi_data4";
renesas,function = "qspi";
};
+
+ vin0_pins: vin0 {
+ renesas,groups = "vin0_data8", "vin0_clk";
+ renesas,function = "vin0";
+ };
};
&scif2 {
@@ -135,6 +140,19 @@
status = "okay";
clock-frequency = <40>;
+
+ composite-in@20 {
+ compatible = "adi,adv7180";
+ reg = <0x20>;
+ remote = <&vin0>;
+
+ port {
+ adv7180: endpoint {
+ bus-width = <8>;
+ remote-endpoint = <&vin0ep>;
+ };
+ };
+ };
};
&mmcif0 {
@@ -193,3 +211,20 @@
};
};
};
+
+/* composite video input */
+&vin0 {
+ status = "okay";
+ pinctrl-0 = <&vin0_pins>;
+ pinctrl-names = "default";
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vin0ep: endpoint {
+ remote-endpoint = <&adv7180>;
+ bus-width = <8>;
+ };
+ };
+};
--
To unsubscribe from this list: send the line "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/2] ARM: shmobile: r8a7794: add VIN DT support
Define the generic R8A7794 part of the VIN[01] device nodes. Add aliases for
the VIN[01] device nodes.
Signed-off-by: Sergei Shtylyov
---
arch/arm/boot/dts/r8a7794.dtsi | 20
1 file changed, 20 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -27,6 +27,8 @@
i2c4 = &i2c4;
i2c5 = &i2c5;
spi0 = &qspi;
+ vin0 = &vin0;
+ vin1 = &vin1;
};
cpus {
@@ -628,6 +630,24 @@
status = "disabled";
};
+ vin0: video@e6ef {
+ compatible = "renesas,vin-r8a7794";
+ reg = <0 0xe6ef 0 0x1000>;
+ interrupts = <0 188 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp8_clks R8A7794_CLK_VIN0>;
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+ };
+
+ vin1: video@e6ef1000 {
+ compatible = "renesas,vin-r8a7794";
+ reg = <0 0xe6ef1000 0 0x1000>;
+ interrupts = <0 189 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp8_clks R8A7794_CLK_VIN1>;
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+ };
+
clocks {
#address-cells = <2>;
#size-cells = <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 0/2] Add VIN and ADV7180 device tree support for R8A7794/SILK board
Hello. Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's 'renesas-devel-20150819-v4.2-rc7' tag. Here we add the VIN and ADV7180 video decoder device tree support on the R8A7794/SILK board. The patchset requires previously posted SILK SDHI1 support patch in order to apply and R8A7794/SILK I2C1 support in order to apply and build. [1/2] ARM: shmobile: r8a7794: add VIN DT support [2/2] ARM: shmobile: silk: add VIN0/ADV7180 DT support MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] ARM: dts: rockchip: correct regulator power states for suspend
When getting translated from a downstream device tree that used slightly
different DT bindings, these regulators got labeled with the
"on-in-suspend" state, when they were actually supposed to be turned off
for S3 suspend. This was harmless, but not intentional, AFAICT.
Let's turn them off to get the optimal power state.
Signed-off-by: Brian Norris
Cc: Alexandru M Stan
Cc: Douglas Anderson
---
New in v2. Tested jaq.
arch/arm/boot/dts/rk3288-veyron-jerry.dts | 2 +-
arch/arm/boot/dts/rk3288-veyron-pinky.dts | 2 +-
arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
index 42d724559915..60bd6e91e308 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
@@ -99,7 +99,7 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-state-mem {
- regulator-on-in-suspend;
+ regulator-off-in-suspend;
};
};
};
diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
index 25eb4b0c1330..94b56e33d947 100644
--- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
@@ -109,7 +109,7 @@
regulator-boot-on;
regulator-name = "vcc18_lcd";
regulator-state-mem {
- regulator-on-in-suspend;
+ regulator-off-in-suspend;
};
};
};
diff --git a/arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi
b/arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi
index 788468a48163..b5334ecff13c 100644
--- a/arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi
@@ -93,7 +93,7 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-state-mem {
- regulator-on-in-suspend;
+ regulator-off-in-suspend;
};
};
@@ -102,7 +102,7 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-state-mem {
- regulator-on-in-suspend;
+ regulator-off-in-suspend;
};
};
};
--
2.5.0.276.gf5e568e
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] ARM: dts: rockchip: correct regulator PM properties
This DTS file was submitted with non-upstream bindings. I happened
across this while reviewing the jaq DTS.
Signed-off-by: Brian Norris
Cc: Alexandru M Stan
Cc: Douglas Anderson
---
Did not test minnie
v1 -> v2:
- use "off-in-suspend", as that's the equivalent to the downstream
'regulator-suspend-mem-disabled'
arch/arm/boot/dts/rk3288-veyron-minnie.dts | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index 0e30bd6bf92b..8fd8ef2c72da 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -128,12 +128,16 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-name = "vcc33_touch";
- regulator-suspend-mem-disabled;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
vcc5v_touch: SWITCH_REG2 {
regulator-name = "vcc5v_touch";
- regulator-suspend-mem-disabled;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
};
};
--
2.5.0.276.gf5e568e
--
To unsubscribe from this list: send the line "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] ARM: dts: rockchip: add veyron-jaq board
a.k.a. Haier Chromebook 11
Signed-off-by: Brian Norris
Cc: Alexandru M Stan
Cc: Douglas Anderson
---
v1 -> v2:
- add overlooked DT binding doc
- fixup regulator suspend state for LDO_REG2
Documentation/devicetree/bindings/arm/rockchip.txt | 7 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk3288-veyron-jaq.dts| 176 +
3 files changed, 184 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3288-veyron-jaq.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
b/Documentation/devicetree/bindings/arm/rockchip.txt
index af58cd74aeff..7fc7cf5c79d2 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -31,6 +31,13 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "netxeon,r89", "rockchip,rk3288";
+- Google Jaq (Haier Chromebook 11):
+Required root node properties:
+ - compatible = "google,veyron-jaq-rev5", "google,veyron-jaq-rev4",
+"google,veyron-jaq-rev3", "google,veyron-jaq-rev2",
+"google,veyron-jaq-rev1", "google,veyron-jaq",
+"google,veyron", "rockchip,rk3288";
+
- Google Jerry (Hisense Chromebook C11 and more):
Required root node properties:
- compatible = "google,veyron-jerry-rev7", "google,veyron-jerry-rev6",
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7805a6541a38..a08ca6c3d76e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -490,6 +490,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-firefly-beta.dtb \
rk3288-firefly.dtb \
rk3288-r89.dtb \
+ rk3288-veyron-jaq.dtb \
rk3288-veyron-jerry.dtb \
rk3288-veyron-minnie.dtb \
rk3288-veyron-pinky.dtb \
diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
new file mode 100644
index ..c2f52cfb4d06
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
@@ -0,0 +1,176 @@
+/*
+ * Google Veyron Jaq Rev 1+ board device tree source
+ *
+ * Copyright 2015 Google, Inc
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk3288-veyron-chromebook.dtsi"
+#include "cros-ec-sbs.dtsi"
+
+/ {
+ model = "Google Jaq";
+ compatible = "google,veyron-jaq-rev5", "google,veyron-jaq-rev4",
+"google,veyron-jaq-rev3", "google,veyron-jaq-rev2",
+"google,veyron-jaq-rev1", "google,veyron-jaq",
+"google,veyron", "rockchip,rk3288";
+
+ panel_regulator: panel-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio7 14 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_enable_h>;
+ regulator-name = "panel_regulator";
+ vin-supply = <&vcc33_sys>;
+ };
+
+ vcc18_lcd: vcc18-lcd {
+ compat
Re: [PATCH 0/2] Add R8A7794/SILK I2C device tree support
On 08/20/2015 12:57 AM, Sergei Shtylyov wrote: Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's 'renesas-devel-20150819-v4.2-rc7' tag. Here we add the I2C device tree support for the R8A7794/SILK board. [1/2] ARM: shmobile: r8a7794: add I2C DT support [2/2] ARM: shmobile: silk: add I2C1 DT support Simon, actually the above patch is atop of my SILK SDHI1 patch but should apply with offsets atop of your tag. MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: shmobile: silk: add I2C1 DT support
Define the SILK board dependent part of the I2C1 device node.
Signed-off-by: Sergei Shtylyov
---
arch/arm/boot/dts/r8a7794-silk.dts | 13 +
1 file changed, 13 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7794-silk.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7794-silk.dts
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -85,6 +85,11 @@
renesas,function = "intc";
};
+ i2c1_pins: i2c1 {
+ renesas,groups = "i2c1";
+ renesas,function = "i2c1";
+ };
+
mmcif0_pins: mmcif0 {
renesas,groups = "mmc_data8", "mmc_ctrl";
renesas,function = "mmc";
@@ -124,6 +129,14 @@
};
};
+&i2c1 {
+ pinctrl-0 = <&i2c1_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+ clock-frequency = <40>;
+};
+
&mmcif0 {
pinctrl-0 = <&mmcif0_pins>;
pinctrl-names = "default";
--
To unsubscribe from this list: send the line "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/2] ARM: shmobile: r8a7794: add I2C DT support
Define the generic R8A7794 parts of the I2C[0-5] device nodes.
Based on the original patch by Koji Matsuoka .
Signed-off-by: Sergei Shtylyov
---
arch/arm/boot/dts/r8a7794.dtsi | 73 +
1 file changed, 73 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -20,6 +20,12 @@
#size-cells = <2>;
aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
spi0 = &qspi;
};
@@ -500,6 +506,73 @@
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
+ };
+
+ /* The memory map in the User's Manual maps the cores to bus numbers */
+ i2c0: i2c@e6508000 {
+ compatible = "renesas,i2c-r8a7794";
+ reg = <0 0xe6508000 0 0x40>;
+ interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7794_CLK_I2C0>;
+ power-domains = <&cpg_clocks>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@e6518000 {
+ compatible = "renesas,i2c-r8a7794";
+ reg = <0 0xe6518000 0 0x40>;
+ interrupts = <0 288 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7794_CLK_I2C1>;
+ power-domains = <&cpg_clocks>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@e653 {
+ compatible = "renesas,i2c-r8a7794";
+ reg = <0 0xe653 0 0x40>;
+ interrupts = <0 286 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7794_CLK_I2C2>;
+ power-domains = <&cpg_clocks>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c3: i2c@e654 {
+ compatible = "renesas,i2c-r8a7794";
+ reg = <0 0xe654 0 0x40>;
+ interrupts = <0 290 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7794_CLK_I2C3>;
+ power-domains = <&cpg_clocks>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c4: i2c@e652 {
+ compatible = "renesas,i2c-r8a7794";
+ reg = <0 0xe652 0 0x40>;
+ interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7794_CLK_I2C4>;
+ power-domains = <&cpg_clocks>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c@e6528000 {
+ compatible = "renesas,i2c-r8a7794";
+ reg = <0 0xe6528000 0 0x40>;
+ interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7794_CLK_I2C5>;
+ power-domains = <&cpg_clocks>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
};
mmcif0: mmc@ee20 {
--
To unsubscribe from this list: send the line "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/2] Add R8A7794/SILK I2C device tree support
Hello. Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's 'renesas-devel-20150819-v4.2-rc7' tag. Here we add the I2C device tree support for the R8A7794/SILK board. [1/2] ARM: shmobile: r8a7794: add I2C DT support [2/2] ARM: shmobile: silk: add I2C1 DT support 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/7] drm/vc4: Add KMS support for Raspberry Pi.
Hi Eric,
only a few nits.
Am 18.08.2015 um 23:54 schrieb Eric Anholt:
This is the start of a full VC4 driver. Right now this just supports
configuring the display using a pre-existing video mode (because
changing the pixel clock isn't available yet, and doesn't work when it
is). However, this is enough for fbcon and bringing up X using
xf86-video-modesetting.
Signed-off-by: Eric Anholt
---
v2: Drop FB_HELPER select thanks to Archit's patches. Do manual init
ordering instead of using the .load hook. Structure registration
more like tegra's, but still using the typical "component" code.
Drop no-op hooks for atomic_begin and mode_fixup() now that
they're optional. Drop sentinel in Makefile. Fix minor style
nits I noticed on another reread.
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/vc4/Kconfig | 13 +
drivers/gpu/drm/vc4/Makefile | 17 +
drivers/gpu/drm/vc4/vc4_bo.c | 52
drivers/gpu/drm/vc4/vc4_crtc.c| 565 ++
drivers/gpu/drm/vc4/vc4_debugfs.c | 38 +++
drivers/gpu/drm/vc4/vc4_drv.c | 271
drivers/gpu/drm/vc4/vc4_drv.h | 120
drivers/gpu/drm/vc4/vc4_hdmi.c| 633 ++
drivers/gpu/drm/vc4/vc4_hvs.c | 161 ++
drivers/gpu/drm/vc4/vc4_kms.c | 84 +
drivers/gpu/drm/vc4/vc4_plane.c | 320 +++
drivers/gpu/drm/vc4/vc4_regs.h| 562 +
14 files changed, 2839 insertions(+)
create mode 100644 drivers/gpu/drm/vc4/Kconfig
create mode 100644 drivers/gpu/drm/vc4/Makefile
create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h
[...]
+static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
+{
+ struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+ struct drm_crtc_state *state = crtc->state;
+ struct drm_display_mode *mode = &state->adjusted_mode;
+ u32 vactive = (mode->vdisplay >>
+ ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0));
+ u32 format = PV_CONTROL_FORMAT_24;
+ bool debug_dump_regs = false;
+
+ if (debug_dump_regs) {
+ DRM_INFO("CRTC %d regs before:\n", drm_crtc_index(crtc));
+ vc4_crtc_dump_regs(vc4_crtc);
+ }
+
+ /* This is where we would set the pixel clock. */
+
+ /* Reset the PV fifo. */
+ CRTC_WRITE(PV_CONTROL, 0);
+ CRTC_WRITE(PV_CONTROL, PV_CONTROL_FIFO_CLR | PV_CONTROL_EN);
+ CRTC_WRITE(PV_CONTROL, 0);
+
+ CRTC_WRITE(PV_HORZA,
+ VC4_SET_FIELD(mode->htotal - mode->hsync_end,
+PV_HORZA_HBP) |
+ VC4_SET_FIELD(mode->hsync_end - mode->hsync_start,
+PV_HORZA_HSYNC));
+ CRTC_WRITE(PV_HORZB,
+ VC4_SET_FIELD(mode->hsync_start - mode->hdisplay,
+PV_HORZB_HFP) |
+ VC4_SET_FIELD(mode->hdisplay, PV_HORZB_HACTIVE));
+
+ CRTC_WRITE(PV_VERTA,
+ VC4_SET_FIELD(mode->vtotal - mode->vsync_end,
+PV_VERTA_VBP) |
+ VC4_SET_FIELD(mode->vsync_end - mode->vsync_start,
+PV_VERTA_VSYNC));
+ CRTC_WRITE(PV_VERTB,
+ VC4_SET_FIELD(mode->vsync_start - mode->vdisplay,
+PV_VERTB_VFP) |
+ VC4_SET_FIELD(vactive, PV_VERTB_VACTIVE));
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
+ /* Write PV_VERTA_EVEN/VERTB_EVEN */
+ }
checkpatch complains here. Is this intended to have only a comment? Is
it a TODO?
[...]
--- /dev/null
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -0,0 +1,120 @@
+/*
+ * Copyright (C) 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "drmP.h"
+#include "drm_gem_cma_helper.h"
+
+struct vc4_dev {
+ struct drm_device *dev;
+
+ struct vc4_hdmi *hdmi;
+ struct vc4_hvs *hvs;
+ struct vc4_crtc *crtc[3];
+};
+
+static inline struct vc4_dev *
+to_vc4_dev(struct drm_device *dev)
+{
+ return (struct vc4_dev *)dev->dev_private;
+}
+
+struct vc4_bo {
+ struct drm_gem_cma_object base;
+};
+
+static inline struct vc4_bo *
+to_vc4_bo(struct drm_gem_object *bo)
+{
+
Re: [PATCH 1/2] powerpc/qman: Change fsl,qman-channel-id to cell-index
On Wed, Aug 19, 2015 at 03:52:55PM -0500, Pledge Roy-R01356 wrote: > Sorry for digging up an old thread here Scott, but we never did close on this > discussion. See my replies inline below > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Tuesday, May 12, 2015 6:46 PM > > To: Pledge Roy-R01356 > > Cc: linuxppc-...@lists.ozlabs.org; devicetree@vger.kernel.org; Bucur > > Madalin-Cristian-B32716 > > Subject: Re: [PATCH 1/2] powerpc/qman: Change fsl,qman-channel-id to cell- > > index > > > > On Tue, 2015-05-12 at 16:19 -0500, Pledge Roy-R01356 wrote: > > > > > > > > > > I don't believe this is correct - let me explain the rational why > > > > > we had two > > > > properties in the QMan portal to begin with. > > > > > > > > > > The two properties in question are cell-index and fsl,qman-channel-id. > > > > > > > > > > The cell-index property is used in u-boot as an index for the > > > > > software portal > > > > ID when adding the fsl,liodn from the U-boot table into the device tree. > > > > > > > > The device tree is not supposed to contain arbitrary software > > > > identifiers. > > > > > > I agree - this is why the original device tree bindings removed > > > cell-index as it can be calculated. > > Unfortunately u-boot relied on > > > this value being present so to be backward compatible we don't have a > > > way to remove it. I'm not sure on what the procedure is to change > > > things u-boot relies on, > > > > Generally the procedure is that we don't change it. It wouldn't be so bad > > if > > using an old U-Boot just meant that datapath doesn't work with upstream > > kernels (since that doesn't work now), but a dts that makes existing U-Boot > > crash is another matter. > > If this is true then we can never remove the cell-index property. Correct. > The cell-index in this case is referring to the portal index which > could be calculated from the qman-portal@ value. My preference > would be to eliminate cell-index and replace it with this calculation > but that would mean older u-boot would fail to work with newer kernel. > While the bug that caused older u-boot to crash if this property is > annoying this has been addressed in more recent u-boots. I can't > comment on a policy where u-boot must always boot newer version of > Linux - that means Linux will have to drag along baggage like this > property for a long time (forever?). The baggage isn't particularly onerous. It's just using a suboptimal property name. The semantics are exactly the same as fsl,qman-channel-id. > > > > > > > > > The fsl,qman-channel-id property is used in Linux and corresponds > > > > > to a hardware value that indicates which channel is dedicated to > > > > > the software portal. > > > > > > > > > > While I'm not aware of a current SoC where the channel ID for a > > > > > software portal does not match the index (i.e. SWP 0 uses channel > > > > > 0, > > > > > etc.) > > > > > > > > Thus there's no backward compatibility issue with redefining > > > > cell-index to mean the channel ID. > > > > > > Channel IDs do change and are defined when the SoC is created > > > > But for SoCs that already exist, they won't change, right? We don't need to > > care about what existing U-Boot does on new SoCs, since U-Boot would > > need to be changed to support the new SoC at all. > > This code isn't looking at SoC product numbers - the whole point of > putting this in the device tree is to avoid doing just that. If we had > to add code for each SoC to u-boot we may as well get rid of the device > tree and hardcode this configuration in the source file that is SoC > specific. The point of putting this in the device tree is to avoid per-SoC code in *Linux*. U-Boot does use the device tree for similar purposes on some platforms, but that's not something we've done yet. I'm not sure how it's relevant, though. How would it be different if we had fsl,qman-channel-id and no cell-index? When I mentioned U-Boot needing to be updated for new SoCs, I meant to run in general, not specifically the QMan code. So, needing to be compatible with existing QMan code is only an issue for SoCs where an older U-Boot actually exists. We don't need to care what the old code would have done on newer SoCs. > > > (look at checks for QMan versions and adjustments for Pool Channel > > > IDs in the driver). If the channel ID for portal 0 ever becomes non > > > zero we just end up having to make a mess in the code or reintroduce > > > this field. > > > > What defines that portal as "portal 0"? > > Portal 0 is portal 0 because it is at offset 0 in the QMan portal > memory region. Portal 1 is at 0x4000 etc... Note that this is not the > case for forthcoming ARM devices as portals are distributed at 64K > intervals. However since the device tree parsing code for ARM is > separate from the PPC code this will not pose any issue. I don't understand why it would cause an issue in any case. U-Boot would need to either
Re: [PATCH 3/4 v3][RFC] arm64: renesas: Add initial r8a7795 SoC support
Hello,
On Wednesday 19 August 2015 09:49:28 Geert Uytterhoeven wrote:
> On Tue, Aug 18, 2015 at 2:20 AM, Michael Turquette wrote:
> > Quoting Geert Uytterhoeven (2015-08-04 05:34:06)
> >> On Tue, Aug 4, 2015 at 2:22 PM, Laurent Pinchart wrote:
> >>> On Monday 03 August 2015 01:53:23 Kuninori Morimoto wrote:
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -0,0 +1,93 @@
> +/ {
> + clocks {
> >>>
> >>> Let's try to make it right from the start on Gen3. The CPG node should
> >>> be a direct child of the bus node mentioned above, and the MSTP clocks
> >>> should be children of the CPG node.
> >>
> >> Agreed.
> >>
> >>> I'm not sure where to put the non-memory-mapped clocks though, should
> >>> they be directly under the root node ? It would make sense for
> >>> extal_clk, but how about the fixed-factor clocks ? Should they be
> >>> children of the CPG node too ?
> >>
> >> I believe the current trend is to put clocks like "extal_clk" under the
> >> root node. As the fixed-factor clocks are generated by the CPG module,
> >> and we do have a device node for it, I'd make them children of the CPG
> >> node, too.
> >>
> >> Any comments from the clk+dt experts?
> >
> > I don't know if anyone is an expert ;-)
> >
> > extal_clk should be under the root node. That is true for all
> > board-level clocks and clock controllers.
>
> OK.
I agree too.
> > Within the SoC we want to model the clock controller as a node in DT,
> > not necessarily all of the individual clocks. So you definitely need a
> > "cpg" node in DT with #clock-cells > 0.
>
> OK.
Ditto.
> > Whether or not you enumerate the individual clocks in DT is up to you. I
> > do not like the data-driven approach of putting the clock definition
> > data into DT. It makes it awkward to do things like set a flag on a
> > single clock later on. Simply using the clock controller phandle plus
> > one or more offsets is preferred over a per-clock phandle.
> >
> > Stephen and I have been discussing what a formal clock-controller
> > binding would look like, and one item we came up with is that any
> > sub-nodes of the controller would not be allowed to have a #clock-cells
> > property.
>
> Does that mean #clock-cells is inherited from the parent (cpg) node, or does
> that preclude having any "fixed-factor-clock" or "renesas,cpg-div6-clock"
> (both use #clock-cells = <0>), or "renesas,cpg-mstp-clocks" subnodes?
We were thinking about moving the fixed factor clocks and the gate clocks as
subnodes as the CPG DT node, as those clocks are provided by the CPG. This
would require setting #clock-cells to 1 in the CPG node and to 0 in some of
the subnodes. If that's not allowed, how should the fixed factor clocks and
gate clocks be declared ?
> > Also, while you're thinking about the perfect clock binding, please do
> > consider dropping clock-output-names if you can. Specifying clock-names
> > alongside the clocks property inside of the consumer node is a bit more
> > elegant in my opinion. This is also a bit easier if you think about
> > expressing your clock data with C inside of your provider driver.
>
> Makes sense. I don't think anything relies on the "clock-output-names"
> ... currently.
>
> I was going to use it for identifying the GIC clock, though:
>
> --- a/drivers/clk/shmobile/clk-mstp.c
> +++ b/drivers/clk/shmobile/clk-mstp.c
> @@ -144,6 +144,9 @@ cpg_mstp_clock_register(const char *name, const char
> *paren init.name = name;
> init.ops = &cpg_mstp_clock_ops;
> init.flags = CLK_IS_BASIC | CLK_SET_RATE_PARENT;
> + /* INTC-SYS is the module clock of the GIC, and must not be disabled
> */
> + if (!strcmp(name, "intc-sys"))
> + init.flags |= CLK_ENABLE_HAND_OFF;
> init.parent_names = &parent_name;
> init.num_parents = 1;
>
> (FTR, on R-Car Gen3 the clock is called "intc-ap", not "intc-sys", doh...).
>
> This does put some reliance on (undocumented) naming in DT, though, so not
> having the "clock-output-names" would solve that.
Using the clock name is indeed very messy, let's avoid that.
> However, while "intc-sys"/"intc-ap" (if existent) is always MSTP408, MSTP408
> is used for other modules on R-Car Gen1 and most older SoCs. so it would
> complicate the driver code.
How about setting the flag based on information provided in DT ?
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + extal_clk: extal_clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <0>;
> + clock-output-names = "extal";
> + };
> + cpg_clocks: cpg_clocks@e615 {
> + compatible = "renesas,r8a7795-cpg-clocks",
> + "renesas,rcar-gen3-cpg-clocks";
> +
RE: [PATCH 1/2] powerpc/qman: Change fsl,qman-channel-id to cell-index
Sorry for digging up an old thread here Scott, but we never did close on this discussion. See my replies inline below > -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, May 12, 2015 6:46 PM > To: Pledge Roy-R01356 > Cc: linuxppc-...@lists.ozlabs.org; devicetree@vger.kernel.org; Bucur > Madalin-Cristian-B32716 > Subject: Re: [PATCH 1/2] powerpc/qman: Change fsl,qman-channel-id to cell- > index > > On Tue, 2015-05-12 at 16:19 -0500, Pledge Roy-R01356 wrote: > > > > > > > > I don't believe this is correct - let me explain the rational why > > > > we had two > > > properties in the QMan portal to begin with. > > > > > > > > The two properties in question are cell-index and fsl,qman-channel-id. > > > > > > > > The cell-index property is used in u-boot as an index for the > > > > software portal > > > ID when adding the fsl,liodn from the U-boot table into the device tree. > > > > > > The device tree is not supposed to contain arbitrary software identifiers. > > > > I agree - this is why the original device tree bindings removed > > cell-index as it can be calculated. > Unfortunately u-boot relied on > > this value being present so to be backward compatible we don't have a > > way to remove it. I'm not sure on what the procedure is to change > > things u-boot relies on, > > Generally the procedure is that we don't change it. It wouldn't be so bad if > using an old U-Boot just meant that datapath doesn't work with upstream > kernels (since that doesn't work now), but a dts that makes existing U-Boot > crash is another matter. If this is true then we can never remove the cell-index property. The cell-index in this case is referring to the portal index which could be calculated from the qman-portal@ value. My preference would be to eliminate cell-index and replace it with this calculation but that would mean older u-boot would fail to work with newer kernel. While the bug that caused older u-boot to crash if this property is annoying this has been addressed in more recent u-boots. I can't comment on a policy where u-boot must always boot newer version of Linux - that means Linux will have to drag along baggage like this property for a long time (forever?). > > > > > > > The fsl,qman-channel-id property is used in Linux and corresponds > > > > to a hardware value that indicates which channel is dedicated to > > > > the software portal. > > > > > > > > While I'm not aware of a current SoC where the channel ID for a > > > > software portal does not match the index (i.e. SWP 0 uses channel > > > > 0, > > > > etc.) > > > > > > Thus there's no backward compatibility issue with redefining > > > cell-index to mean the channel ID. > > > > Channel IDs do change and are defined when the SoC is created > > But for SoCs that already exist, they won't change, right? We don't need to > care about what existing U-Boot does on new SoCs, since U-Boot would > need to be changed to support the new SoC at all. This code isn't looking at SoC product numbers - the whole point of putting this in the device tree is to avoid doing just that. If we had to add code for each SoC to u-boot we may as well get rid of the device tree and hardcode this configuration in the source file that is SoC specific. > > > (look at checks for QMan versions and adjustments for Pool Channel > > IDs in the driver). If the channel ID for portal 0 ever becomes non > > zero we just end up having to make a mess in the code or reintroduce > > this field. > > What defines that portal as "portal 0"? Portal 0 is portal 0 because it is at offset 0 in the QMan portal memory region. Portal 1 is at 0x4000 etc... Note that this is not the case for forthcoming ARM devices as portals are distributed at 64K intervals. However since the device tree parsing code for ARM is separate from the PPC code this will not pose any issue. > > > > > it is possible that future SoCs could stray from this model, there > > > > is no reason for portal index to equal channel ID at all times. > > > > > > How can future SoCs dictate how we assign a software-defined > identifier? > > > If software wants it to be the same as the channel id, then it will be. > > > > > > If there is some aspect of the hardware itself (not the > > > documentation) that cell-index currently corresponds to, other than > > > the channel id, please make that clear. > > > > Channel ID is defined in the SoC RTL - it is not controlled by > > software and it is not a software assigned identifier. It is not > > possible for SW to set these values. > > I said "other than the channel id". In particular, I was asking about the > concept of "portal index". The only thing cell-index indicates is the offset of the portal in the QMan address space. Linux doesn't look at this value. If we can get past the issue of old u-boots not working I would happily produce patches that remove this from u-boot and the device trees and start using unit-address for det
Re: [PATCH v2 1/7] drm/vc4: Add devicetree bindings for VC4.
Hi Eric,
Am 18.08.2015 um 23:54 schrieb Eric Anholt:
VC4 is the GPU (display and 3D) subsystem present on the 2835 and some
other Broadcom SoCs.
This binding follows the model of msm, imx, sti, and others, where
there is a subsystem node for the whole GPU, with nodes for the
individual HW components within it.
Signed-off-by: Eric Anholt
---
v2: Extend the commit message, fix several nits from Stephen Warren.
.../devicetree/bindings/gpu/brcm,bcm-vc4.txt | 79 ++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
new file mode 100644
index 000..1b9fedc
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
@@ -0,0 +1,79 @@
+Broadcom VC4 GPU
+
+The VC4 device present on the Raspberry Pi includes a display system
+with HDMI output and the HVS scaler for compositing display planes.
+
+Required properties for VC4:
+- compatible: Should be "brcm,vc4"
+- crtcs: List of phandles of pixelvalve scanout engines
+- hvss:List of phandles of HVS video scalers
+- encoders:List of phandles of output encoders (HDMI, SDTV)
+
+Required properties for Pixel Valve:
+- compatible: Should be "brcm,vc4-pixelvalve"
+- reg: Physical base address and length of the PV's registers
+- interrupts: The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HVS:
+- compatible: Should be "brcm,vc4-hvs"
+- reg: Physical base address and length of the HVS's registers
+- interrupts: The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HDMI
+- compatible: Should be "brcm,vc4-hdmi"
+- reg: Physical base address and length of the two register ranges
+ ("HDMI" and "HD", in that order)
+- interrupts: The interrupt numbers
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+- ddc: phandle of the I2C controller used for DDC EDID probing
+- crtc:phandle to the pixelvalve CRTC the HDMI encoder is
attached to
+
+Optional properties for HDMI:
+- hpd-gpio:The GPIO pin for HDMI hotplug detect (if it doesn't appear
+ as an interrupt/status bit in the HDMI controller
+ itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt
+
+Example:
+pv0: brcm,vc4-pixelvalve@7e206000 {
AFAIK the DT node name should describe the function and usually don't
have a vendor prefix. Here some possible suggestions without deeper
knowledge of the hardware function:
pv0: pixelvalve
+ compatible = "brcm,vc4-pixelvalve";
+ reg = <0x7e206000 0x100>;
+ interrupts = <2 13>; /* pwa2 */
+};
+
+pv1: brcm,vc4-pixelvalve@7e207000 {
pv1: pixelvalve
+ compatible = "brcm,vc4-pixelvalve";
+ reg = <0x7e207000 0x100>;
+ interrupts = <2 14>; /* pwa1 */
+};
+
+pv2: brcm,vc4-pixelvalve@7e807000 {
pv2: pixelvalve
+ compatible = "brcm,vc4-pixelvalve";
+ reg = <0x7e807000 0x100>;
+ interrupts = <2 10>; /* pixelvalve */
+};
+
+hvs: brcm,hvs@7e40 {
hvs: hvs
+ compatible = "brcm,vc4-hvs";
+ reg = <0x7e40 0x6000>;
+ interrupts = <2 1>;
+};
+
+hdmi: brcm,vc4-hdmi@7e902000 {
hdmi: hdmi
+ compatible = "brcm,vc4-hdmi";
+ reg = <0x7e902000 0x600>,
+ <0x7e808000 0x100>;
+ interrupts = <2 8>, <2 9>;
+ ddc = <&i2c2>;
+ hpd-gpio = <&gpio 46 GPIO_ACTIVE_HIGH>;
+ crtc = <&pv2>;
+};
+
+vc4: vc4@0x7e4c {
vc4: gpu
Regards
Stefan
+ compatible = "brcm,vc4";
+
+ crtcs = <&pv0>, <&pv1>, <&pv2>;
+ encoders = <&hdmi>;
+ hvss = <&hvs>;
+};
--
To unsubscribe from this list: send the line "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/address: Don't loop forever in of_find_matching_node_by_address().
From: David Daney
If the internal call to of_address_to_resource() fails, we end up
looping forever in of_find_matching_node_by_address(). This can be
caused by a defective device tree, or calling with an incorrect
matches argument.
Fix by calling of_find_matching_node() unconditionally at the end of
the loop.
Signed-off-by: David Daney
---
drivers/of/address.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8bfda6a..384574c 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -845,10 +845,10 @@ struct device_node
*of_find_matching_node_by_address(struct device_node *from,
struct resource res;
while (dn) {
- if (of_address_to_resource(dn, 0, &res))
- continue;
- if (res.start == base_address)
+ if (!of_address_to_resource(dn, 0, &res) &&
+ res.start == base_address)
return dn;
+
dn = of_find_matching_node(dn, matches);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 5/8] staging: usage documentation for simple fpga bus
Acked-by: Moritz Fischer On Wed, Aug 19, 2015 at 11:28 AM, atull wrote: > On Mon, 17 Aug 2015, Pavel Machek wrote: > >> On Thu 2015-08-13 12:37:29, at...@opensource.altera.com wrote: >> > From: Alan Tull >> > >> > Add a document spelling out usage of the simple fpga bus. >> > >> > Signed-off-by: Alan Tull >> >> Acked-by: Pavel Machek >> >> Pavel > Hi Pavel, > > Thanks! > > Alan > >> -- >> (english) http://www.livejournal.com/~pavelmachek >> (cesky, pictures) >> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 v10 5/8] staging: usage documentation for simple fpga bus
On Mon, 17 Aug 2015, Pavel Machek wrote: > On Thu 2015-08-13 12:37:29, at...@opensource.altera.com wrote: > > From: Alan Tull > > > > Add a document spelling out usage of the simple fpga bus. > > > > Signed-off-by: Alan Tull > > Acked-by: Pavel Machek > > Pavel Hi Pavel, Thanks! Alan > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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] input: ti_am335x_tsc: Add open delay parameter
On Wed, Aug 12, 2015 at 01:44:22PM -0500, Michael Welling wrote:
> On Wed, Aug 12, 2015 at 11:56:36AM +0530, Vignesh R wrote:
> > Hi Michael,
> >
> > + Dmitry
> >
> > On 08/12/2015 12:15 AM, Michael Welling wrote:
> > > Adds a device tree parameter to set the open delay on the touchscreen
> > > conversion steps. Increasing this parameter helps the touch accuracy on
> > > some screens.
> > >
> > > Signed-off-by: Michael Welling
> > > ---
> > > .../bindings/input/touchscreen/ti-tsc-adc.txt | 5 +
> > > drivers/input/touchscreen/ti_am335x_tsc.c | 18
> > > ++
> > > 2 files changed, 19 insertions(+), 4 deletions(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
> > > b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
> > > index b1163bf..cb11fda 100644
> > > --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
> > > @@ -41,6 +41,11 @@ Optional properties:
> > >charge step, so this does in fact function as a
> > >hardware knob for adjusting the amount of "settling
> > >time".
> > > + ti,open-delay: Open delay applied to all touchscreen conversion steps.
> > > + The value corresponds to the number of ADC clock
> > > + cycles to wait after applying the step configuration
> > > + registers and before sending the start of ADC
> > > + conversion. Maximum value is 0x3.
> > >
> >
> > Since open-delay is per step, is it not better to allow specifying
> > open-delay per step like ti,chan-step-opendelay of adc? This will help
> > control open-delay for all the four wires.
>
> Do you see any reason why you would want a different delay for each step of
> the conversion on the same touchscreen?
>
> The user would need to know the number of steps what each of the steps do.
>
Comments?
Any other concerns?
> >
> > > - child "adc"
> > > ti,chan-step-opendelay: List of open delays for each channel of
> > > diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
> > > b/drivers/input/touchscreen/ti_am335x_tsc.c
> > > index 191a1b8..37a9729 100644
> > > --- a/drivers/input/touchscreen/ti_am335x_tsc.c
> > > +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
> > > @@ -54,6 +54,7 @@ struct titsc {
> > > u32 inp_xp, inp_xn, inp_yp, inp_yn;
> > > u32 step_mask;
> > > u32 charge_delay;
> > > + u32 open_delay;
> > > };
> > >
> > > static unsigned int titsc_readl(struct titsc *ts, unsigned int reg)
> > > @@ -148,7 +149,7 @@ static void titsc_step_config(struct titsc *ts_dev)
> > > end_step = first_step + tsc_steps;
> > > for (i = end_step - ts_dev->coordinate_readouts; i < end_step; i++) {
> > > titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
> > > - titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
> > > + titsc_writel(ts_dev, REG_STEPDELAY(i), ts_dev->open_delay);
> > > }
> > >
> > > config = 0;
> > > @@ -172,7 +173,7 @@ static void titsc_step_config(struct titsc *ts_dev)
> > > end_step = first_step + ts_dev->coordinate_readouts;
> > > for (i = first_step; i < end_step; i++) {
> > > titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
> > > - titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
> > > + titsc_writel(ts_dev, REG_STEPDELAY(i), ts_dev->open_delay);
> > > }
> > >
> > > /* Make CHARGECONFIG same as IDLECONFIG */
> > > @@ -188,13 +189,13 @@ static void titsc_step_config(struct titsc *ts_dev)
> > > STEPCONFIG_INP(ts_dev->inp_xp);
> > > titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
> > > titsc_writel(ts_dev, REG_STEPDELAY(end_step),
> > > - STEPCONFIG_OPENDLY);
> > > + ts_dev->open_delay);
> > >
> > > end_step++;
> > > config |= STEPCONFIG_INP(ts_dev->inp_yn);
> > > titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
> > > titsc_writel(ts_dev, REG_STEPDELAY(end_step),
> > > - STEPCONFIG_OPENDLY);
> > > + ts_dev->open_delay);
> > >
> > > /* The steps end ... end - readouts * 2 + 2 and bit 0 for TS_Charge */
> > > stepenable = 1;
> > > @@ -392,6 +393,15 @@ static int titsc_parse_dt(struct platform_device
> > > *pdev,
> > > dev_warn(&pdev->dev, "ti,charge-delay not specified\n");
> > > }
> > >
> > > + err = of_property_read_u32(node, "ti,open-delay",
> > > +&ts_dev->open_delay);
> > > + /*
> > > + * If ti,open-delay value is not specified, then use
> > > + * STEPCONFIG_OPENDLY as the default value.
> > > + */
> > > + if (err < 0)
> > > + ts_dev->open_delay = STEPCONFIG_OPENDLY;
> > > +
> > > return of_property_read_u32_array(node, "ti,wire
[PATCH 1/2] ARM: qcom: add mdio bus on IPQ806x/AP148
Ethernet switch on AP148 is connected through MDIO using GPIO 0 and 1.
We'll add the new node using the bitbang driver on these two pins.
Signed-off-by: Mathieu Olivari
---
arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
index 6886d09..d73df24 100644
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -19,8 +19,9 @@
};
};
- alias {
+ aliases {
serial0 = &uart4;
+ mdio-gpio0 = &mdio0;
};
chosen {
@@ -84,6 +85,15 @@
};
};
};
+
+ mdio0_pins: mdio0_pins {
+ mux {
+ pins = "gpio0", "gpio1";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+ };
};
sata-phy@1b40 {
@@ -93,5 +103,24 @@
sata@2900 {
status = "ok";
};
+
+ mdio0: mdio {
+ compatible = "virtual,mdio-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpios = <&qcom_pinmux 1 0 &qcom_pinmux 0 0>;
+ pinctrl-0 = <&mdio0_pins>;
+ pinctrl-names = "default";
+
+ phy0: ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
+
+ phy4: ethernet-phy@4 {
+ device_type = "ethernet-phy";
+ reg = <4>;
+ };
+ };
};
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: qcom: add GMAC nodes to IPQ806x platforms
This change adds GMAC nodes to IPQ806x platforms, both to the dtsi and
to the AP148 dts. This will provide ethernet connectivity to the device.
Signed-off-by: Mathieu Olivari
---
arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 33
arch/arm/boot/dts/qcom-ipq8064.dtsi | 86
2 files changed, 119 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
index d73df24..0958fa3 100644
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -94,6 +94,18 @@
bias-disable;
};
};
+
+ rgmii2_pins: rgmii2_pins {
+ mux {
+ pins = "gpio27", "gpio28", "gpio29",
+ "gpio30", "gpio31", "gpio32",
+ "gpio51", "gpio52", "gpio59",
+ "gpio60", "gpio61", "gpio62";
+ function = "rgmii2";
+ drive-strength = <8>;
+ bias-disable;
+ };
+ };
};
sata-phy@1b40 {
@@ -122,5 +134,26 @@
reg = <4>;
};
};
+
+ gmac1: ethernet@3720 {
+ status = "ok";
+ phy-mode = "rgmii";
+ phy-handle = <&phy4>;
+ qcom,id = <1>;
+
+ pinctrl-0 = <&rgmii2_pins>;
+ pinctrl-names = "default";
+ };
+
+ gmac2: ethernet@3740 {
+ status = "ok";
+ phy-mode = "sgmii";
+ qcom,id = <2>;
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 2f270d7..6706a56 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -336,6 +336,92 @@
compatible = "syscon";
reg = <0x01200600 0x100>;
};
+
+ nss_common: syscon@0300 {
+ compatible = "syscon";
+ reg = <0x0300 0x>;
+ };
+
+ qsgmii_csr: syscon@1bb0 {
+ compatible = "syscon";
+ reg = <0x1bb0 0x01FF>;
+ };
+
+ gmac0: ethernet@3700 {
+ device_type = "network";
+ compatible = "qcom,ipq806x-gmac";
+ reg = <0x3700 0x20>;
+ interrupts = ;
+ interrupt-names = "macirq";
+
+ qcom,nss-common = <&nss_common>;
+ qcom,qsgmii-csr = <&qsgmii_csr>;
+
+ clocks = <&gcc GMAC_CORE1_CLK>;
+ clock-names = "stmmaceth";
+
+ resets = <&gcc GMAC_CORE1_RESET>;
+ reset-names = "stmmaceth";
+
+ status = "disabled";
+ };
+
+ gmac1: ethernet@3720 {
+ device_type = "network";
+ compatible = "qcom,ipq806x-gmac";
+ reg = <0x3720 0x20>;
+ interrupts = ;
+ interrupt-names = "macirq";
+
+ qcom,nss-common = <&nss_common>;
+ qcom,qsgmii-csr = <&qsgmii_csr>;
+
+ clocks = <&gcc GMAC_CORE2_CLK>;
+ clock-names = "stmmaceth";
+
+ resets = <&gcc GMAC_CORE2_RESET>;
+ reset-names = "stmmaceth";
+
+ status = "disabled";
+ };
+
+ gmac2: ethernet@3740 {
+ device_type = "network";
+ compatible = "qcom,ipq806x-gmac";
+ reg = <0x3740 0x20>;
+ interrupts = ;
+ interrupt-names = "macirq";
+
+ qcom,nss-common = <&nss_common>;
+ qcom,qsgmii-csr = <&qsgmii_csr>;
+
+ clocks = <&gcc GMAC_CORE3_CLK>;
+ clock-names = "stmmaceth";
+
+ resets = <&gcc GMAC_CORE3_RESET>;
+ reset-names = "stmmaceth";
+
+ status = "disabled";
+ };
+
+
Re: [PATCH 2/2] dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller
On 08/19/2015 07:12 PM, Vinod Koul wrote:
> On Tue, Jul 28, 2015 at 11:38:06AM +0200, Lars-Peter Clausen wrote:
>> +static void axi_dmac_start_transfer(struct axi_dmac_chan *chan)
>> +{
>> +struct axi_dmac *dmac = chan_to_axi_dmac(chan);
>> +struct virt_dma_desc *vdesc;
>> +struct axi_dmac_desc *desc;
>> +struct axi_dmac_sg *sg;
>> +unsigned int flags = 0;
>> +unsigned int val;
>> +
>> +val = axi_dmac_read(dmac, AXI_DMAC_REG_START_TRANSFER);
>> +if (val) /* Queue is full, wait for the next SOT IRQ */
>> +return;
>> +
>> +desc = chan->next_desc;
>> +
>> +if (!desc) {
>> +vdesc = vchan_next_desc(&chan->vchan);
>> +if (!vdesc)
>> +return;
>> +list_move_tail(&vdesc->node, &chan->active_descs);
>> +desc = to_axi_dmac_desc(vdesc);
>> +}
>> +sg = &desc->sg[desc->num_submitted];
>> +
>> +desc->num_submitted++;
>> +if (desc->num_submitted == desc->num_sgs)
>> +chan->next_desc = NULL;
>> +else
>> +chan->next_desc = desc;
>> +
>> +sg->id = axi_dmac_read(dmac, AXI_DMAC_REG_TRANSFER_ID);
>> +
>> +if (axi_dmac_dest_is_mem(chan)) {
>> +axi_dmac_write(dmac, AXI_DMAC_REG_DEST_ADDRESS, sg->dest_addr);
>> +axi_dmac_write(dmac, AXI_DMAC_REG_DEST_STRIDE, sg->dest_stride);
>> +}
>> +
>> +if (axi_dmac_src_is_mem(chan)) {
>> +axi_dmac_write(dmac, AXI_DMAC_REG_SRC_ADDRESS, sg->src_addr);
>> +axi_dmac_write(dmac, AXI_DMAC_REG_SRC_STRIDE, sg->src_stride);
>> +}
>> +
>> +/*
>> + * If the hardware supports cyclic transfers and there is no callback to
>> + * call, enable hw cyclic mode to avoid unnecessary interrupts.
>> + */
>> +if (chan->hw_cyclic && desc->cyclic && !desc->vdesc.tx.callback)
>> +flags |= AXI_DMAC_FLAG_CYCLIC;
>> +
>> +axi_dmac_write(dmac, AXI_DMAC_REG_X_LENGTH, sg->x_len - 1);
>> +axi_dmac_write(dmac, AXI_DMAC_REG_Y_LENGTH, sg->y_len - 1);
>> +axi_dmac_write(dmac, AXI_DMAC_REG_FLAGS, flags);
>> +axi_dmac_write(dmac, AXI_DMAC_REG_START_TRANSFER, 1);
>> +}
>
> On Wed, Aug 19, 2015 at 06:55:34PM +0200, Lars-Peter Clausen wrote:
>> On 08/19/2015 06:32 PM, Vinod Koul wrote:
>>> On Tue, Jul 28, 2015 at 11:38:06AM +0200, Lars-Peter Clausen wrote:
+ desc = axi_dmac_alloc_desc(sg_len);
+ if (!desc)
+ return NULL;
+
+ for_each_sg(sgl, sg, sg_len, i) {
+ if (!axi_dmac_check_addr(chan, sg_dma_address(sg)) ||
+ !axi_dmac_check_len(chan, sg_dma_len(sg))) {
+ kfree(desc);
+ return NULL;
+ }
+
+ if (direction == DMA_DEV_TO_MEM)
+ desc->sg[i].dest_addr = sg_dma_address(sg);
+ else
+ desc->sg[i].src_addr = sg_dma_address(sg);
>>> where is device side programming ?
>>
>> in the start_transfer() function.
>
> I must have missed that but still don't see it here, can you point me
Oh you mean the DMA address for the device? It's a dedicated bus on the
device side, so there is no address to program on the device side.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] spi: mediatek: fix spi incorrect endian usage
On Wed, Aug 19, 2015 at 11:37:58AM +0800, Leilk Liu wrote: > TX_ENDIAN/RX_ENDIAN bits define whether to reverse the endian > order of the data DMA from/to memory. The endian order should > keep the same with cpu endian. This doesn't apply, probably because it depends on your stylistic changes patch - this is an example of the issues I was mentioning with stylistic changes getting in the waty of fixes :( signature.asc Description: Digital signature
Re: [PATCH 2/2] dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller
On Tue, Jul 28, 2015 at 11:38:06AM +0200, Lars-Peter Clausen wrote:
> +static void axi_dmac_start_transfer(struct axi_dmac_chan *chan)
> +{
> + struct axi_dmac *dmac = chan_to_axi_dmac(chan);
> + struct virt_dma_desc *vdesc;
> + struct axi_dmac_desc *desc;
> + struct axi_dmac_sg *sg;
> + unsigned int flags = 0;
> + unsigned int val;
> +
> + val = axi_dmac_read(dmac, AXI_DMAC_REG_START_TRANSFER);
> + if (val) /* Queue is full, wait for the next SOT IRQ */
> + return;
> +
> + desc = chan->next_desc;
> +
> + if (!desc) {
> + vdesc = vchan_next_desc(&chan->vchan);
> + if (!vdesc)
> + return;
> + list_move_tail(&vdesc->node, &chan->active_descs);
> + desc = to_axi_dmac_desc(vdesc);
> + }
> + sg = &desc->sg[desc->num_submitted];
> +
> + desc->num_submitted++;
> + if (desc->num_submitted == desc->num_sgs)
> + chan->next_desc = NULL;
> + else
> + chan->next_desc = desc;
> +
> + sg->id = axi_dmac_read(dmac, AXI_DMAC_REG_TRANSFER_ID);
> +
> + if (axi_dmac_dest_is_mem(chan)) {
> + axi_dmac_write(dmac, AXI_DMAC_REG_DEST_ADDRESS, sg->dest_addr);
> + axi_dmac_write(dmac, AXI_DMAC_REG_DEST_STRIDE, sg->dest_stride);
> + }
> +
> + if (axi_dmac_src_is_mem(chan)) {
> + axi_dmac_write(dmac, AXI_DMAC_REG_SRC_ADDRESS, sg->src_addr);
> + axi_dmac_write(dmac, AXI_DMAC_REG_SRC_STRIDE, sg->src_stride);
> + }
> +
> + /*
> + * If the hardware supports cyclic transfers and there is no callback to
> + * call, enable hw cyclic mode to avoid unnecessary interrupts.
> + */
> + if (chan->hw_cyclic && desc->cyclic && !desc->vdesc.tx.callback)
> + flags |= AXI_DMAC_FLAG_CYCLIC;
> +
> + axi_dmac_write(dmac, AXI_DMAC_REG_X_LENGTH, sg->x_len - 1);
> + axi_dmac_write(dmac, AXI_DMAC_REG_Y_LENGTH, sg->y_len - 1);
> + axi_dmac_write(dmac, AXI_DMAC_REG_FLAGS, flags);
> + axi_dmac_write(dmac, AXI_DMAC_REG_START_TRANSFER, 1);
> +}
On Wed, Aug 19, 2015 at 06:55:34PM +0200, Lars-Peter Clausen wrote:
> On 08/19/2015 06:32 PM, Vinod Koul wrote:
> > On Tue, Jul 28, 2015 at 11:38:06AM +0200, Lars-Peter Clausen wrote:
> >> + desc = axi_dmac_alloc_desc(sg_len);
> >> + if (!desc)
> >> + return NULL;
> >> +
> >> + for_each_sg(sgl, sg, sg_len, i) {
> >> + if (!axi_dmac_check_addr(chan, sg_dma_address(sg)) ||
> >> + !axi_dmac_check_len(chan, sg_dma_len(sg))) {
> >> + kfree(desc);
> >> + return NULL;
> >> + }
> >> +
> >> + if (direction == DMA_DEV_TO_MEM)
> >> + desc->sg[i].dest_addr = sg_dma_address(sg);
> >> + else
> >> + desc->sg[i].src_addr = sg_dma_address(sg);
> > where is device side programming ?
>
> in the start_transfer() function.
I must have missed that but still don't see it here, can you point me
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller
On 08/19/2015 06:32 PM, Vinod Koul wrote:
> On Tue, Jul 28, 2015 at 11:38:06AM +0200, Lars-Peter Clausen wrote:
>> +active = axi_dmac_active_desc(chan);
>> +if (!active)
>> +return;
>> +
>> +if (active->cyclic) {
>> +vchan_cyclic_callback(&active->vdesc);
>> +} else {
>> +while (active &&
> do you need to check this, you did that few lines back?
It gets overwritten in the loop.
[...]
>
>> +static struct dma_async_tx_descriptor *axi_dmac_prep_slave_sg(
>> +struct dma_chan *c, struct scatterlist *sgl,
>> +unsigned int sg_len, enum dma_transfer_direction direction,
>> +unsigned long flags, void *context)
>> +{
>> +struct axi_dmac_chan *chan = to_axi_dmac_chan(c);
>> +struct axi_dmac_desc *desc;
>> +struct scatterlist *sg;
>> +unsigned int i;
>> +
>> +if (direction != chan->direction)
>
> are the channels unidirectional
yes.
>
>> +return NULL;
>> +
>> +desc = axi_dmac_alloc_desc(sg_len);
>> +if (!desc)
>> +return NULL;
>> +
>> +for_each_sg(sgl, sg, sg_len, i) {
>> +if (!axi_dmac_check_addr(chan, sg_dma_address(sg)) ||
>> +!axi_dmac_check_len(chan, sg_dma_len(sg))) {
>> +kfree(desc);
>> +return NULL;
>> +}
>> +
>> +if (direction == DMA_DEV_TO_MEM)
>> +desc->sg[i].dest_addr = sg_dma_address(sg);
>> +else
>> +desc->sg[i].src_addr = sg_dma_address(sg);
> where is device side programming ?
in the start_transfer() function.
>
>> +
>> +if (axi_dmac_dest_is_mem(chan) && axi_dmac_src_is_mem(chan))
>> +chan->direction = DMA_MEM_TO_MEM;
>> +else if (!axi_dmac_dest_is_mem(chan) && axi_dmac_src_is_mem(chan))
>> +chan->direction = DMA_MEM_TO_DEV;
>> +else if (axi_dmac_dest_is_mem(chan) && !axi_dmac_src_is_mem(chan))
>> +chan->direction = DMA_DEV_TO_MEM;
>> +else
>> +chan->direction = DMA_DEV_TO_DEV;
>
> ok this seems to answer my other question but is this something we are
> specifying in SW or capability of a channel?
That's a capability of the hardware.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/5] arm/arm64: add smccc ARCH32
On Wed, Aug 19, 2015 at 09:40:25AM +0100, Jens Wiklander wrote: > Adds helpers to do SMC based on ARM SMC Calling Convention. > CONFIG_HAVE_SMCCC is enabled for architectures that may support > the SMC instruction. It's the responsibility of the caller to > know if the SMC instruction is supported by the platform. [...] > diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S > new file mode 100644 > index 000..3ce7fe8 > --- /dev/null > +++ b/arch/arm64/kernel/smccc-call.S > @@ -0,0 +1,34 @@ > +/* > + * Copyright (c) 2015, Linaro Limited > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License Version 2 as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + */ > +#include > + > +#define SMC_PARAM_W0_OFFS 0 > +#define SMC_PARAM_W2_OFFS 8 > +#define SMC_PARAM_W4_OFFS 16 > +#define SMC_PARAM_W6_OFFS 24 > + > +/* void smccc_call32(struct smccc_param32 *param) */ > +ENTRY(smccc_call32) > + stp x28, x30, [sp, #-16]! Why are you saving lr? > + mov x28, x0 > + ldp w0, w1, [x28, #SMC_PARAM_W0_OFFS] > + ldp w2, w3, [x28, #SMC_PARAM_W2_OFFS] > + ldp w4, w5, [x28, #SMC_PARAM_W4_OFFS] > + ldp w6, w7, [x28, #SMC_PARAM_W6_OFFS] > + smc #0 > + stp w0, w1, [x28, #SMC_PARAM_W0_OFFS] > + stp w2, w3, [x28, #SMC_PARAM_W2_OFFS] > + ldp x28, x30, [sp], #16 > + ret > +ENDPROC(smccc_call32) Could we deal with this like we do for PSCI instead? (see __invoke_psci_fn_smc). We could also then rename psci-call.S to fw-call.S and stick this in there too. Will -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[linux-sunxi][PATCH] ARM: sun7i: dt: Add new Olimex A20 EVB device
From: Marcus Cooper
The A20-SOM-EVB is a reference design of a 2-layer board for the
A20-SOM.
It expands the features of A20-SOM by adding VGA connector, HDMI
connector, audio In/Out, LCD connector, 2 Mpix camera, gigabit
Ethernet, SATA, USB-OTG and 2 USB hosts.
This patch adds basic support for the device
https://www.olimex.com/Products/SOM/A20/A20-SOM-EVB/
More information on the SOM can be found here
http://linux-sunxi.org/Olimex_A20-SOM.
Signed-off-by: Marcus Cooper
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/sun7i-a20-olinuxino-evb.dts | 233 ++
2 files changed, 234 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-olinuxino-evb.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 6d7cec1..fdbda9b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -613,6 +613,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-olinuxino-lime.dtb \
sun7i-a20-olinuxino-lime2.dtb \
sun7i-a20-olinuxino-micro.dtb \
+ sun7i-a20-olinuxino-evb.dtb \
sun7i-a20-orangepi.dtb \
sun7i-a20-orangepi-mini.dtb \
sun7i-a20-pcduino3.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-evb.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-evb.dts
new file mode 100644
index 000..a0071fa
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-evb.dts
@@ -0,0 +1,233 @@
+/*
+ * Copyright 2015 - Marcus Cooper
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "Olimex A20-OLinuXino-EVB";
+ compatible = "olimex,a20-olinuxino-evb", "allwinner,sun7i-a20";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins_olinuxinoevb>;
+
+ green {
+ label = "a20-olinuxino-evb:green:usr";
+ gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ reg_axp_ipsout: axp_ipsout {
+ compatible = "regulator-fixed";
+ regulator-name = "axp-ipsout";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+};
+
+&ahci {
+ target-supply = <®_ahci_5v>;
+ status = "okay";
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&gmac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_pins_rgmii_a>;
+ phy = <&phy1>;
+ phy-mode = "rgmii";
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status
Re: [PATCH v3 0/8] ARM: sunxi: Add Reduced Serial Bus support
On Wed, Aug 19, 2015 at 12:20:01PM +0800, Chen-Yu Tsai wrote: > Hi everyone, > > This is my third attempt at adding support for Allwinner's Reduced > Serial Bus (RSB), which is used to communicate with PMICs and other > peripherals on their newer SoCs, such as the A23/A33/A80. This is flagged as something that is specific to the Allwinner SoCs. Why add generic regmap support rather than just implement the regmap reg_read() and reg_write() in a regmap in the controller driver? Are there expected to be other controller drivers from other vendors? signature.asc Description: Digital signature
Re: [PATCH v4 3/3] mtd: add SMEM parser for QCOM platforms
On Tue 18 Aug 14:04 PDT 2015, Mathieu Olivari wrote:
> On QCOM platforms using MTD devices storage (such as IPQ806x), SMEM is
> used to store partition layout. This new parser can now be used to read
> SMEM and use it to register an MTD layout according to its content.
>
Still looks good, but you should have added:
Acked-by: Bjorn Andersson
> Signed-off-by: Mathieu Olivari
> ---
>
> Notes:
> v2:
> *Release the SPI device reference after looking it up (put_device())
> *Represent SMEM data as __le32 rather than u32
> *Move new DT nodes in their proper respective location
> *Address readability concerns in MTD parser
>
> v3:
> *Redefine SMEM functions prototypes for better readability
> *Duplicate MTD name instead of pointing to SMEM string location in case
> mtd layer tries to free it
> *Rework some of the comments
>
> v4:
> *Fix case in the license string
>
> drivers/mtd/Kconfig | 7 ++
> drivers/mtd/Makefile | 1 +
> drivers/mtd/qcom_smem_part.c | 246
> +++
> 3 files changed, 254 insertions(+)
> create mode 100644 drivers/mtd/qcom_smem_part.c
>
> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
> index a03ad29..debc887 100644
> --- a/drivers/mtd/Kconfig
> +++ b/drivers/mtd/Kconfig
> @@ -155,6 +155,13 @@ config MTD_BCM47XX_PARTS
> This provides partitions parser for devices based on BCM47xx
> boards.
>
> +config MTD_QCOM_SMEM_PARTS
> + tristate "QCOM SMEM partitioning support"
> + depends on QCOM_SMEM
> + help
> + This provides partitions parser for QCOM devices using SMEM
> + such as IPQ806x.
> +
> comment "User Modules And Translation Layers"
>
> #
> diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
> index 99bb9a1..b3c7de4 100644
> --- a/drivers/mtd/Makefile
> +++ b/drivers/mtd/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_MTD_AFS_PARTS) += afs.o
> obj-$(CONFIG_MTD_AR7_PARTS) += ar7part.o
> obj-$(CONFIG_MTD_BCM63XX_PARTS) += bcm63xxpart.o
> obj-$(CONFIG_MTD_BCM47XX_PARTS) += bcm47xxpart.o
> +obj-$(CONFIG_MTD_QCOM_SMEM_PARTS) += qcom_smem_part.o
>
> # 'Users' - code which presents functionality to userspace.
> obj-$(CONFIG_MTD_BLKDEVS)+= mtd_blkdevs.o
> diff --git a/drivers/mtd/qcom_smem_part.c b/drivers/mtd/qcom_smem_part.c
> new file mode 100644
> index 000..b4f8acc
> --- /dev/null
> +++ b/drivers/mtd/qcom_smem_part.c
> @@ -0,0 +1,246 @@
> +/*
> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/* Processor/host identifier for the application processor */
> +#define QCOM_SMEM_GLOBAL 0
> +
> +/* SMEM items index */
> +#define SMEM_AARM_PARTITION_TABLE9
> +#define SMEM_BOOT_FLASH_TYPE 421
> +#define SMEM_BOOT_FLASH_BLOCK_SIZE 424
> +
> +/* SMEM Flash types */
> +#define SMEM_FLASH_NAND 2
> +#define SMEM_FLASH_SPI 6
> +
> +#define SMEM_PART_NAME_SZ16
> +#define SMEM_PARTS_MAX 32
> +
> +struct smem_partition {
> + char name[SMEM_PART_NAME_SZ];
> + __le32 start;
> + __le32 size;
> + __le32 attr;
> +};
> +
> +struct smem_partition_table {
> + u8 magic[8];
> + __le32 version;
> + __le32 len;
> + struct smem_partition parts[SMEM_PARTS_MAX];
> +};
> +
> +/* SMEM Magic values in partition table */
> +static const u8 SMEM_PTABLE_MAGIC[] = {
> + 0xaa, 0x73, 0xee, 0x55,
> + 0xdb, 0xbd, 0x5e, 0xe3,
> +};
> +
> +static int qcom_smem_get_flash_blksz(void)
> +{
> + int ret;
> + size_t size;
> + u64 *smem_blksz;
> +
> + ret = qcom_smem_get(QCOM_SMEM_GLOBAL, SMEM_BOOT_FLASH_BLOCK_SIZE,
> + (void **) &smem_blksz, &size);
> +
> + if (ret < 0) {
> + pr_err("Unable to read flash blksz from SMEM\n");
> + return -ENOENT;
> + }
> +
> + if (size != sizeof(*smem_blksz)) {
> + pr_err("Invalid flash blksz size in SMEM\n");
> + return -EINVAL;
> + }
> +
> + /* Sanity check block size value before casting it */
> + if (*smem_blksz > INT_MAX) {
> + pr_err("Invalid flash block size in SMEM\n");
> + return -EINVAL;
> + }
> +
> + return (int) *smem_blksz;
> +}
> +
> +static int qcom_smem_get_flash_type(void)
> +{
> + int r
Re: [PATCH v4 2/3] ARM: qcom: add SMEM device node to IPQ806x dts
On Tue 18 Aug 14:04 PDT 2015, Mathieu Olivari wrote:
> SMEM is used on IPQ806x to store various board related information such
> as boot device and flash partition layout. We'll declare it as a device
> so we can make use of it thanks to the new SMEM soc driver.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Mathieu Olivari
> ---
>
> Notes:
> v2:
> *Rename "smem" tag into "smem_region"
>
> arch/arm/boot/dts/qcom-ipq8064.dtsi | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi
> b/arch/arm/boot/dts/qcom-ipq8064.dtsi
> index 8d366ae..9834c94 100644
> --- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
> @@ -55,7 +55,7 @@
> no-map;
> };
>
> - smem@4100 {
> + smem_region: smem@4100 {
> reg = <0x4100 0x20>;
> no-map;
> };
> @@ -341,4 +341,10 @@
>
> #hwlock-cells = <1>;
> };
> +
> + smem {
> + compatible = "qcom,smem";
> + memory-region = <&smem_region>;
> + hwlocks = <&sfpb_mutex 3>;
> + };
> };
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] ARM: qcom: add SFPB nodes to IPQ806x dts
On Tue 18 Aug 14:04 PDT 2015, Mathieu Olivari wrote:
> Add one new node to the ipq806x.dtsi file to declare & register the
> hardware spinlock devices. This mechanism is required to be used by
> other drivers such as SMEM.
>
Still looks good, but you should have added:
Reviewed-by: Bjorn Andersson
> Signed-off-by: Mathieu Olivari
> ---
> arch/arm/boot/dts/qcom-ipq8064.dtsi | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi
> b/arch/arm/boot/dts/qcom-ipq8064.dtsi
> index 9f727d8..8d366ae 100644
> --- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
> @@ -329,5 +329,16 @@
> #reset-cells = <1>;
> };
>
> + sfpb_mutex_block: syscon@1200600 {
> + compatible = "syscon";
> + reg = <0x01200600 0x100>;
> + };
> + };
> +
> + sfpb_mutex: sfpb-mutex {
> + compatible = "qcom,sfpb-mutex";
> + syscon = <&sfpb_mutex_block 4 4>;
> +
> + #hwlock-cells = <1>;
> };
> };
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 3/6] PCI: designware: Add ARM64 support
Hi Lucas
First of all many thanks for the quick reply, really appreciated
> -Original Message-
> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: Wednesday, August 19, 2015 4:37 PM
> To: Gabriele Paoloni
> Cc: Wangzhou (B); Bjorn Helgaas; jingooh...@gmail.com; Pratyush Anand;
> Arnd Bergmann; li...@arm.linux.org.uk; thomas.petazzoni@free-
> electrons.com; lorenzo.pieral...@arm.com; james.mo...@arm.com;
> liviu.du...@arm.com; ja...@lakedaemon.net; r...@kernel.org; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; liudongdong (C); qiujiang; xuwei (O); Liguozhu (Kenneth)
> Subject: Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
>
> Hi Gab,
>
> Am Mittwoch, den 19.08.2015, 15:16 + schrieb Gabriele Paoloni:
> > Hi Lucas
> >
> > I have rewritten the patch to take into account multiple controllers.
> >
> > As you can see now there is a static var in dw_pcie_host_init() that
> tracks
> > the bus numbers used.
>
> This is wrong. The DT specifies the valid bus number range. You can not
> just assign the next free bus number to the root bus.
I think this is what is being done in
http://lxr.free-electrons.com/source/arch/arm/kernel/bios32.c#L495
and currently designware assigns the root bus number in
http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L730
In general I agree with you but if you look at all the current drivers
based on designware none of them define the "bus-range" dtb property.
Therefore doing as you say would break the current driver when we have
multiple controllers...am I right?
If that is the case in order to fix this in the way you say I would need
to assign "bus-range" for all the PCIe drivers with multiple controllers:
in this case I would split the default range evenly (that is, if we have
two controllers I would define "bus-range" 0-127 and 128-255)
If you think this solution is ok I can go for it. My only doubt was about
touching other vendors DTBs
>
> It is perfectly valid to have a bus range of 0x00-0x10 assigned to one
> instance and 0x50-0xff to the next instance. Additional with PCIe
> hotplug you may not use the full range of the bus numbers on one
> instance at the first scan, but only later populate more buses when
> more
> bridges are added to the tree.
>
> > Drivers that do not specify the bus range in the DTB set pp-
> >root_bus_nr = DW_ROOT_NR_UNDEFINED.
> > Designware will check if the flag is set and will use the automatic
> bus range
> > assignment.
>
> No, please lets get rid of this assignment altogether. The glue drivers
> have no business in assigning the bus range. Please remove the
> pp->root_bus_nr assignment from all the glue drivers.
>
> "bus range" is a generic DW PCIe property, so just parse the root bus
> number from the DT, it is handled the same way for all the DW based
> PCIe
> drivers. The bindings specifies that if the bus range property is
> missing the range is 0x00-0xff, so you can default to 0 as the root bus
> number in that case.
>
> Also I would think this conversion warrants a patch on its own and
> should not be mixed in the ARM64 support patch.
>
> Regards,
> Lucas
>
> > Instead if the driver assigns pp->root_bus_nr according to the dtb,
> designwware
> > will use the value passed in by the driver.
> > Below the relevant section:
> >
> >
> > + static int root_bus_nr = 0;
> > ...
> > + mutex_lock(&root_bus_nr_mux);
> > +
> > + if (pp->root_bus_nr != DW_ROOT_NR_UNDEFINED)
> > + root_bus_nr = pp->root_bus_nr;
> > +
> > + bus = pci_create_root_bus(pp->dev, root_bus_nr, &dw_pcie_ops,
> > + pp, &res);
> > + if (!bus) {
> > + mutex_unlock(&root_bus_nr_mux);
> > + return -ENOMEM;
> > + }
> > +
> > + root_bus_nr += bus->busn_res.end + 1;
> > + mutex_unlock(&root_bus_nr_mux);
> >
> > Please let me know what you think...
> >
> > Many Thanks
> >
> > Gab
> > --
> >
> > From: gabriele paoloni
> >
> > This patch tries to unify ARM32 and ARM64 PCIe in designware driver.
> Delete
> > function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct
> hw_pci,
> > move related operations to dw_pcie_host_init.
> > Also set pp->root_bus_nr = DW_ROOT_NR_UNDEFINED in all the drivers
> that
> > are based on designware to flag that the drivers do not read the bus
> > ranges from DT.
> > This patch also adds handling of multiple PCI domains in designware.
> > if the PCI host bridge driver does not specify a root bus number, in
> case
> > of multiple domains, designware will automatillay set the next domain
> root
> > bus number to the last bus number used in the last domain + 1.
> >
> > This patch also try to use of_pci_get_host_bridge_resources for ARM32
> and
> > ARM64 according to the suggestion for Gabriele[1]
> >
> > This patch is based on Gabriele's patch about of_pci_range fix[2]
> >
> > Finally this patch reverts commi
Re: [PATCH 2/2] dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller
On Tue, Jul 28, 2015 at 11:38:06AM +0200, Lars-Peter Clausen wrote:
> + active = axi_dmac_active_desc(chan);
> + if (!active)
> + return;
> +
> + if (active->cyclic) {
> + vchan_cyclic_callback(&active->vdesc);
> + } else {
> + while (active &&
do you need to check this, you did that few lines back?
> +static struct axi_dmac_desc *axi_dmac_alloc_desc(unsigned int num_sgs)
> +{
> + struct axi_dmac_desc *desc;
> +
> + desc = kzalloc(sizeof(struct axi_dmac_desc) +
> + sizeof(struct axi_dmac_sg) * num_sgs, GFP_ATOMIC);
we recommend GFP_NOWAIT for these...
> +static struct dma_async_tx_descriptor *axi_dmac_prep_slave_sg(
> + struct dma_chan *c, struct scatterlist *sgl,
> + unsigned int sg_len, enum dma_transfer_direction direction,
> + unsigned long flags, void *context)
> +{
> + struct axi_dmac_chan *chan = to_axi_dmac_chan(c);
> + struct axi_dmac_desc *desc;
> + struct scatterlist *sg;
> + unsigned int i;
> +
> + if (direction != chan->direction)
are the channels unidirectional
> + return NULL;
> +
> + desc = axi_dmac_alloc_desc(sg_len);
> + if (!desc)
> + return NULL;
> +
> + for_each_sg(sgl, sg, sg_len, i) {
> + if (!axi_dmac_check_addr(chan, sg_dma_address(sg)) ||
> + !axi_dmac_check_len(chan, sg_dma_len(sg))) {
> + kfree(desc);
> + return NULL;
> + }
> +
> + if (direction == DMA_DEV_TO_MEM)
> + desc->sg[i].dest_addr = sg_dma_address(sg);
> + else
> + desc->sg[i].src_addr = sg_dma_address(sg);
where is device side programming ?
> +
> + if (axi_dmac_dest_is_mem(chan) && axi_dmac_src_is_mem(chan))
> + chan->direction = DMA_MEM_TO_MEM;
> + else if (!axi_dmac_dest_is_mem(chan) && axi_dmac_src_is_mem(chan))
> + chan->direction = DMA_MEM_TO_DEV;
> + else if (axi_dmac_dest_is_mem(chan) && !axi_dmac_src_is_mem(chan))
> + chan->direction = DMA_DEV_TO_MEM;
> + else
> + chan->direction = DMA_DEV_TO_DEV;
ok this seems to answer my other question but is this something we are
specifying in SW or capability of a channel?
--
~Vinod
--
To unsubscribe from this list: send the line "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/7] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support
On Wed, Jul 08, 2015 at 05:11:24PM +0100, Peter Griffin wrote:
> +static int
> +st_fdma_elf_sanity_check(struct st_fdma_dev *fdev, const struct firmware *fw)
> +{
> + const char *fw_name = fdev->pdata->fw_name;
> + struct elf32_hdr *ehdr;
> + char class;
> +
> + if (!fw) {
> + dev_err(fdev->dev, "failed to load %s\n", fw_name);
> + return -EINVAL;
> + }
> +
> + if (fw->size < sizeof(struct elf32_hdr)) {
sizeof(*ehdr) ?
> + dev_err(fdev->dev, "Image is too small\n");
> + return -EINVAL;
> + }
> +
> + ehdr = (struct elf32_hdr *)fw->data;
> +
> + /* We only support ELF32 at this point */
> + class = ehdr->e_ident[EI_CLASS];
> + if (class != ELFCLASS32) {
> + dev_err(fdev->dev, "Unsupported class: %d\n", class);
> + return -EINVAL;
> + }
> +
> + if (ehdr->e_ident[EI_DATA] != ELFDATA2LSB) {
> + dev_err(fdev->dev, "Unsupported firmware endianness\n");
would be worth printing the value for debug
> + return -EINVAL;
> + }
> +
> + if (fw->size < ehdr->e_shoff + sizeof(struct elf32_shdr)) {
> + dev_err(fdev->dev, "Image is too small\n");
Again printing size helps when you get a log trace and have no idea why size
was small. Similar one other places
> + dst = st_fdma_seg_to_mem(fdev, da, memsz);
> + if (!dst) {
> + dev_err(dev, "bad phdr da 0x%x mem 0x%x\n", da, memsz);
> + break;
> + }
> +
> + if (phdr->p_filesz)
> + memcpy(dst, elf_data + phdr->p_offset, filesz);
> +
> + if (memsz > filesz)
> + memset(dst + filesz, 0, memsz - filesz);
> +
> + mem_loaded++;
> + }
> +
> + return (mem_loaded != fdev->drvdata->num_mem) ? -EINVAL : 0;
so you are not expecting any segment with PT_LOAD otherwise this check will
fail as num_mem is assigned from e_phnum.
Also perhaps EIO will be better return?
> +}
> +
> +static void st_fdma_enable(struct st_fdma_dev *fdev)
> +{
> + unsigned long hw_id, hw_ver, fw_rev;
> + u32 val;
> +
> + /* disable CPU pipeline clock & reset cpu pipeline */
> + val = FDMA_CLK_GATE_DIS | FDMA_CLK_GATE_RESET;
> + fdma_write(fdev, val, CLK_GATE);
empty line here
> + /* disable SLIM core STBus sync */
> + fdma_write(fdev, FDMA_STBUS_SYNC_DIS, STBUS_SYNC);
> + /* enable cpu pipeline clock */
> + fdma_write(fdev, !FDMA_CLK_GATE_DIS, CLK_GATE);
> +
> + /* clear int & cmd mailbox */
> + fdma_write(fdev, ~0UL, INT_CLR);
> + fdma_write(fdev, ~0UL, CMD_CLR);
here too
> +static int st_fdma_get_fw(struct st_fdma_dev *fdev)
> +{
> + int ret;
> +
> + init_completion(&fdev->fw_ack);
> + atomic_set(&fdev->fw_loaded, 0);
> +
> + ret = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG,
> + fdev->pdata->fw_name, fdev->dev,
> + GFP_KERNEL, fdev, st_fdma_fw_cb);
Isn't doing this in device probe too stringent and holding up load...
> + fdesc = st_fdma_alloc_desc(fchan, sg_len);
> + if (!fdesc) {
> + dev_err(fchan->fdev->dev, "no memory for desc\n");
> + return NULL;
> + }
> +
> + fdesc->iscyclic = false;
> +
> + for_each_sg(sgl, sg, sg_len, i) {
> + hw_node = fdesc->node[i].desc;
> +
> + hw_node->next = fdesc->node[(i + 1) % sg_len].pdesc;
> + hw_node->control = NODE_CTRL_REQ_MAP_DREQ(fchan->dreq_line);
> +
> + if (direction == DMA_MEM_TO_DEV) {
> + hw_node->control |= NODE_CTRL_SRC_INCR;
> + hw_node->control |= NODE_CTRL_DST_STATIC;
> + hw_node->saddr = sg_dma_address(sg);
> + hw_node->daddr = fchan->cfg.dev_addr;
> + } else {
> + hw_node->control |= NODE_CTRL_SRC_STATIC;
> + hw_node->control |= NODE_CTRL_DST_INCR;
> + hw_node->saddr = fchan->cfg.dev_addr;
> + hw_node->daddr = sg_dma_address(sg);
> + }
> +
> + hw_node->nbytes = sg_dma_len(sg);
> + hw_node->generic.length = sg_dma_len(sg);
> + hw_node->generic.sstride = 0;
> + hw_node->generic.dstride = 0;
This looks quite similar to previous one, I think some bits can be reused
> +static int st_fdma_slave_config(struct dma_chan *chan,
> + struct dma_slave_config *slave_cfg)
> +{
> + u32 maxburst = 0, addr = 0;
> + enum dma_slave_buswidth width;
> + struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
> + int ch_id = fchan->vchan.chan.chan_id;
> + struct st_fdma_dev *fdev = fchan->fdev;
> +
> + if (slave_cfg->direction == DMA_DEV_TO_MEM) {
This is depreciated, you can't use direction here. Please save the fields and
then use them in prep_ c
Re: [PATCH v7 3/6] PCI: designware: Add ARM64 support
Hi Gab,
Am Mittwoch, den 19.08.2015, 15:16 + schrieb Gabriele Paoloni:
> Hi Lucas
>
> I have rewritten the patch to take into account multiple controllers.
>
> As you can see now there is a static var in dw_pcie_host_init() that tracks
> the bus numbers used.
This is wrong. The DT specifies the valid bus number range. You can not
just assign the next free bus number to the root bus.
It is perfectly valid to have a bus range of 0x00-0x10 assigned to one
instance and 0x50-0xff to the next instance. Additional with PCIe
hotplug you may not use the full range of the bus numbers on one
instance at the first scan, but only later populate more buses when more
bridges are added to the tree.
> Drivers that do not specify the bus range in the DTB set pp->root_bus_nr =
> DW_ROOT_NR_UNDEFINED.
> Designware will check if the flag is set and will use the automatic bus range
> assignment.
No, please lets get rid of this assignment altogether. The glue drivers
have no business in assigning the bus range. Please remove the
pp->root_bus_nr assignment from all the glue drivers.
"bus range" is a generic DW PCIe property, so just parse the root bus
number from the DT, it is handled the same way for all the DW based PCIe
drivers. The bindings specifies that if the bus range property is
missing the range is 0x00-0xff, so you can default to 0 as the root bus
number in that case.
Also I would think this conversion warrants a patch on its own and
should not be mixed in the ARM64 support patch.
Regards,
Lucas
> Instead if the driver assigns pp->root_bus_nr according to the dtb,
> designwware
> will use the value passed in by the driver.
> Below the relevant section:
>
>
> + static int root_bus_nr = 0;
> ...
> + mutex_lock(&root_bus_nr_mux);
> +
> + if (pp->root_bus_nr != DW_ROOT_NR_UNDEFINED)
> + root_bus_nr = pp->root_bus_nr;
> +
> + bus = pci_create_root_bus(pp->dev, root_bus_nr, &dw_pcie_ops,
> + pp, &res);
> + if (!bus) {
> + mutex_unlock(&root_bus_nr_mux);
> + return -ENOMEM;
> + }
> +
> + root_bus_nr += bus->busn_res.end + 1;
> + mutex_unlock(&root_bus_nr_mux);
>
> Please let me know what you think...
>
> Many Thanks
>
> Gab
> --
>
> From: gabriele paoloni
>
> This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
> function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
> move related operations to dw_pcie_host_init.
> Also set pp->root_bus_nr = DW_ROOT_NR_UNDEFINED in all the drivers that
> are based on designware to flag that the drivers do not read the bus
> ranges from DT.
> This patch also adds handling of multiple PCI domains in designware.
> if the PCI host bridge driver does not specify a root bus number, in case
> of multiple domains, designware will automatillay set the next domain root
> bus number to the last bus number used in the last domain + 1.
>
> This patch also try to use of_pci_get_host_bridge_resources for ARM32 and
> ARM64 according to the suggestion for Gabriele[1]
>
> This patch is based on Gabriele's patch about of_pci_range fix[2]
>
> Finally this patch reverts commit f4c55c5a3f7f "PCI: designware:
> Program ATU with untranslated address". This was discussed in [3]
>
> I have compiled the driver with multi_v7_defconfig. However, I don't have
> ARM32 PCIe related board to do test. It will be appreciated if someone could
> help to test it.
>
> Signed-off-by: Zhou Wang
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Gabriele Paoloni
>
> [1] http://www.spinics.net/lists/linux-pci/msg42194.html
> [2] https://patchwork.ozlabs.org/patch/495018/
> [3] http://www.spinics.net/lists/arm-kernel/msg436779.html
> ---
> drivers/pci/host/pci-dra7xx.c | 15 +--
> drivers/pci/host/pci-exynos.c | 2 +-
> drivers/pci/host/pci-imx6.c| 2 +-
> drivers/pci/host/pci-keystone-dw.c | 2 +-
> drivers/pci/host/pci-keystone.c| 2 +-
> drivers/pci/host/pci-layerscape.c | 2 +-
> drivers/pci/host/pcie-designware.c | 247
> ++---
> drivers/pci/host/pcie-designware.h | 15 +--
> drivers/pci/host/pcie-spear13xx.c | 2 +-
> 9 files changed, 110 insertions(+), 179 deletions(-)
>
> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> index 5678b57..8d598fb 100644
> --- a/drivers/pci/host/pci-dra7xx.c
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -141,15 +141,15 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
> {
> dw_pcie_setup_rc(pp);
>
> - if (pp->io_mod_base)
> - pp->io_mod_base &= CPU_TO_BUS_ADDR;
> + if (pp->io_base)
> + pp->io_base &= CPU_TO_BUS_ADDR;
>
> - if (pp->mem_mod_base)
> - pp->mem_mod_base &= CPU_TO_BUS_ADDR;
> + if (pp->mem_base)
> + pp->mem_base &= CPU_TO_BUS_ADDR;
>
> - if (pp->cfg0_mod_base) {
> - pp->cfg0_mod_base &= CPU_TO_BUS_ADDR;
> -
Re: [PATCH v2 0/2] I2C support for NXP LPC18xx family
On 19 August 2015 at 17:18, Wolfram Sang wrote: > On Sun, Aug 16, 2015 at 08:10:15PM +0200, Joachim Eastwood wrote: >> This patch set adds a I2C driver and documentation for the I2C >> peripheral found on many NXP LPC MCUs. >> >> The driver is a rework of an old driver by Kevin Wells. It has been >> modified to support modern resource allocation, device tree and >> generally cleaned up. Driver was originally written to support the >> LPC2xxx platforms. >> >> Patches based on i2c/for-next and tested on Embedded Artists' LPC4357 >> Dev Kit and Hitex LPC4350 Eval board with several I2C devices. >> >> This version address comments from Wolfram Sang. >> >> Changes since v1: >> - remove dev_dbg() leftovers from development/debugging >> - use i2c_add_adapter >> - change return value on NACK and arb lost >>(I think all the others should be okay as they are) >> - fix 80 char warnings (involved s/reg_base/base) >> - rebase on i2c/for-next >> >> Joachim Eastwood (2): >> i2c: add i2c-lpc2k driver >> doc: dt: add documentation for nxp,lpc1788-i2c > > Applied to for-next, thanks! Thanks, Wolfram. > Changes regarding readl_poll_timeout() can be sent incrementally. Got it. I'll see if I can figure out a way to test the code path properly. regards, Joachim Eastwood -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] Re: [PATCH 2/3] ARM: dts: sun6i: Turn on gmac on Colombus
On Wed, Aug 19, 2015 at 11:17 PM, Maxime Ripard wrote: > On Fri, Aug 07, 2015 at 05:22:34PM +0200, Hans de Goede wrote: >> We've everything we need to support the gmac on Colombus, turn it on. >> >> Signed-off-by: Hans de Goede > > I recall that the phy was powered by one of the AXP221 regulators, > does it require some additional stuff (like a recent u-boot), or does > it just work and my memory is bad :) ? I sort of remember that as well. FYI i have a patch to add axp221.dtsi, though I haven't converted the hummingbird dts yet. ChenYu -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pwm: Add Broadcom BCM7038 PWM controller support
2015-08-19 2:52 GMT-07:00 Thierry Reding : > On Thu, Aug 06, 2015 at 05:55:58PM -0700, Florian Fainelli wrote: >> Add support for the BCM7038-style PWM controller found in all BCM7xxx STB >> SoCs. >> This controller has a hardcoded 2 channels per controller, and cascades a >> variable frequency generator on top of a fixed frequency generator which >> offers >> a range of a 148ns period all the way to ~622ms periods. >> >> Signed-off-by: Florian Fainelli >> --- >> drivers/pwm/Kconfig | 10 ++ >> drivers/pwm/Makefile | 1 + >> drivers/pwm/pwm-brcmstb.c | 323 >> ++ >> 3 files changed, 334 insertions(+) >> create mode 100644 drivers/pwm/pwm-brcmstb.c >> >> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig >> index b1541f40fd8d..28f95cca70ce 100644 >> --- a/drivers/pwm/Kconfig >> +++ b/drivers/pwm/Kconfig >> @@ -111,6 +111,16 @@ config PWM_CLPS711X >> To compile this driver as a module, choose M here: the module >> will be called pwm-clps711x. >> >> +config PWM_BRCMSTB >> + tristate "Broadcom STB PWM support" >> + depends on ARCH_BRCMSTB >> + help >> + Generic PWM framework driver for the Broadcom Set-top-Box >> + SoCs (BCM7xxx). >> + >> + To compile this driver as a module, choose M Here: the module >> + will be called pwm-brcmstb.c. > > Perhaps call it pwm-brcm7xxx? stb sounds more like a use-case > description rather than a hardware model name. We settled on brcmstb as the common denominator for everything that touches Broadcom Set Top Box chips (BCM7xxx), so the regexp we have in MAINTAINERS will match, also 7xxx has a tendency of being caught by vger.kernel.org thinking this is pr0n (I am not kidding). > >> config PWM_EP93XX >> tristate "Cirrus Logic EP93xx PWM support" >> depends on ARCH_EP93XX >> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile >> index ec50eb5b5a8f..dc7b1b82d47e 100644 >> --- a/drivers/pwm/Makefile >> +++ b/drivers/pwm/Makefile >> @@ -7,6 +7,7 @@ obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o >> obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o >> obj-$(CONFIG_PWM_BCM2835)+= pwm-bcm2835.o >> obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o >> +obj-$(CONFIG_PWM_BRCMSTB)+= pwm-brcmstb.o >> obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o >> obj-$(CONFIG_PWM_EP93XX) += pwm-ep93xx.o >> obj-$(CONFIG_PWM_FSL_FTM)+= pwm-fsl-ftm.o >> diff --git a/drivers/pwm/pwm-brcmstb.c b/drivers/pwm/pwm-brcmstb.c >> new file mode 100644 >> index ..0c5cf5cbcf74 >> --- /dev/null >> +++ b/drivers/pwm/pwm-brcmstb.c >> @@ -0,0 +1,323 @@ >> +/* >> + * Broadcom BCM7038 PWM driver >> + * >> + * Copyright (C) 2015 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; either version 2 of the License, or >> + * (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + */ >> + >> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include > > These should be alphabetically sorted. > >> + >> +/* The block has a hardcoded number of 2 channels per controller */ >> +#define NUM_PWM_CHAN 2 > > No need for the define here. You only use this value once, so having the > literal at the place where it's needed prevents people from having to > look the value up. > >> + >> +/* This block is the "UPG" clock domain which is hardcoded a 27Mhz */ >> +#define PWM_DEFAULT_FREQ 2700 > > Do you really need this? Why not simply make the clocks property > required and get rid of this fallback? The block is fairly inflexible in the input frequency it uses, and is always bundled within the same 27Mhz domain on chips, so having a fallback for platform that do not have yet a proper clock provider is both useful and desirable. > >> + >> +#define PWM_CTRL 0x00 >> +#define CTRL_START BIT(0) >> +#define CTRL_OEBBIT(1) >> +#define CTRL_FORCE_HIGH BIT(2) >> +#define CTRL_OPENDRAIN BIT(3) >> +#define CTRL_CHAN_OFFS 4 >> + >> +#define PWM_CTRL20x04 >> +#define CTRL2_OUT_SELECTBIT(0) >> + >> +#define PWM_CWORD_MSB0x08 >> +#define PWM_CWORD_LSB0x0C >> + >> +#define PWM_CH_SIZE 0x8 >> + >> +/* Number of bits for the CWORD value */ >> +#define CWORD_BIT_SIZE 16 >> + >> +/* Maximum control word value allowed when variable-frequency PWM is used >> as a >> + * clock for the constant-frequency PMW. >> + */ >
Re: [PATCH v2 0/2] I2C support for NXP LPC18xx family
On Sun, Aug 16, 2015 at 08:10:15PM +0200, Joachim Eastwood wrote: > This patch set adds a I2C driver and documentation for the I2C > peripheral found on many NXP LPC MCUs. > > The driver is a rework of an old driver by Kevin Wells. It has been > modified to support modern resource allocation, device tree and > generally cleaned up. Driver was originally written to support the > LPC2xxx platforms. > > Patches based on i2c/for-next and tested on Embedded Artists' LPC4357 > Dev Kit and Hitex LPC4350 Eval board with several I2C devices. > > This version address comments from Wolfram Sang. > > Changes since v1: > - remove dev_dbg() leftovers from development/debugging > - use i2c_add_adapter > - change return value on NACK and arb lost >(I think all the others should be okay as they are) > - fix 80 char warnings (involved s/reg_base/base) > - rebase on i2c/for-next > > Joachim Eastwood (2): > i2c: add i2c-lpc2k driver > doc: dt: add documentation for nxp,lpc1788-i2c Applied to for-next, thanks! Changes regarding readl_poll_timeout() can be sent incrementally. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: sun6i: Turn on gmac on Colombus
On Fri, Aug 07, 2015 at 05:22:34PM +0200, Hans de Goede wrote: > We've everything we need to support the gmac on Colombus, turn it on. > > Signed-off-by: Hans de Goede I recall that the phy was powered by one of the AXP221 regulators, does it require some additional stuff (like a recent u-boot), or does it just work and my memory is bad :) ? -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
RE: [PATCH v7 3/6] PCI: designware: Add ARM64 support
Hi Lucas
I have rewritten the patch to take into account multiple controllers.
As you can see now there is a static var in dw_pcie_host_init() that tracks
the bus numbers used.
Drivers that do not specify the bus range in the DTB set pp->root_bus_nr =
DW_ROOT_NR_UNDEFINED.
Designware will check if the flag is set and will use the automatic bus range
assignment.
Instead if the driver assigns pp->root_bus_nr according to the dtb, designwware
will use the value passed in by the driver.
Below the relevant section:
+ static int root_bus_nr = 0;
...
+ mutex_lock(&root_bus_nr_mux);
+
+ if (pp->root_bus_nr != DW_ROOT_NR_UNDEFINED)
+ root_bus_nr = pp->root_bus_nr;
+
+ bus = pci_create_root_bus(pp->dev, root_bus_nr, &dw_pcie_ops,
+ pp, &res);
+ if (!bus) {
+ mutex_unlock(&root_bus_nr_mux);
+ return -ENOMEM;
+ }
+
+ root_bus_nr += bus->busn_res.end + 1;
+ mutex_unlock(&root_bus_nr_mux);
Please let me know what you think...
Many Thanks
Gab
--
From: gabriele paoloni
This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
move related operations to dw_pcie_host_init.
Also set pp->root_bus_nr = DW_ROOT_NR_UNDEFINED in all the drivers that
are based on designware to flag that the drivers do not read the bus
ranges from DT.
This patch also adds handling of multiple PCI domains in designware.
if the PCI host bridge driver does not specify a root bus number, in case
of multiple domains, designware will automatillay set the next domain root
bus number to the last bus number used in the last domain + 1.
This patch also try to use of_pci_get_host_bridge_resources for ARM32 and
ARM64 according to the suggestion for Gabriele[1]
This patch is based on Gabriele's patch about of_pci_range fix[2]
Finally this patch reverts commit f4c55c5a3f7f "PCI: designware:
Program ATU with untranslated address". This was discussed in [3]
I have compiled the driver with multi_v7_defconfig. However, I don't have
ARM32 PCIe related board to do test. It will be appreciated if someone could
help to test it.
Signed-off-by: Zhou Wang
Signed-off-by: Arnd Bergmann
Signed-off-by: Gabriele Paoloni
[1] http://www.spinics.net/lists/linux-pci/msg42194.html
[2] https://patchwork.ozlabs.org/patch/495018/
[3] http://www.spinics.net/lists/arm-kernel/msg436779.html
---
drivers/pci/host/pci-dra7xx.c | 15 +--
drivers/pci/host/pci-exynos.c | 2 +-
drivers/pci/host/pci-imx6.c| 2 +-
drivers/pci/host/pci-keystone-dw.c | 2 +-
drivers/pci/host/pci-keystone.c| 2 +-
drivers/pci/host/pci-layerscape.c | 2 +-
drivers/pci/host/pcie-designware.c | 247 ++---
drivers/pci/host/pcie-designware.h | 15 +--
drivers/pci/host/pcie-spear13xx.c | 2 +-
9 files changed, 110 insertions(+), 179 deletions(-)
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 5678b57..8d598fb 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -141,15 +141,15 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
{
dw_pcie_setup_rc(pp);
- if (pp->io_mod_base)
- pp->io_mod_base &= CPU_TO_BUS_ADDR;
+ if (pp->io_base)
+ pp->io_base &= CPU_TO_BUS_ADDR;
- if (pp->mem_mod_base)
- pp->mem_mod_base &= CPU_TO_BUS_ADDR;
+ if (pp->mem_base)
+ pp->mem_base &= CPU_TO_BUS_ADDR;
- if (pp->cfg0_mod_base) {
- pp->cfg0_mod_base &= CPU_TO_BUS_ADDR;
- pp->cfg1_mod_base &= CPU_TO_BUS_ADDR;
+ if (pp->cfg0_base) {
+ pp->cfg0_base &= CPU_TO_BUS_ADDR;
+ pp->cfg1_base &= CPU_TO_BUS_ADDR;
}
dra7xx_pcie_establish_link(pp);
@@ -288,6 +288,7 @@ static int __init dra7xx_add_pcie_port(struct dra7xx_pcie
*dra7xx,
pp = &dra7xx->pp;
pp->dev = dev;
+ pp->root_bus_nr = DW_ROOT_NR_UNDEFINED;
pp->ops = &dra7xx_pcie_host_ops;
pp->irq = platform_get_irq(pdev, 1);
diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index f9f468d..ed03a8f 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -530,7 +530,7 @@ static int __init exynos_add_pcie_port(struct pcie_port *pp,
}
}
- pp->root_bus_nr = -1;
+ pp->root_bus_nr = DW_ROOT_NR_UNDEFINED;
pp->ops = &exynos_pcie_host_ops;
ret = dw_pcie_host_init(pp);
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 233a196..0efac85 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -551,7 +551,7 @@ static int __init imx6_add_pcie_port(struct pcie_port *pp,
}
}
- pp->root_bus_nr = -1;
+ pp->root_bus_nr = DW_ROOT_NR_UNDEFINED;
Re: [PATCH 3/3] ARM: dts: sun6i: Columbus: Add i2c controller for communicating with the LCD
On Fri, Aug 07, 2015 at 05:22:35PM +0200, Hans de Goede wrote: > The Colombus development kit uses an optional 2048x1536 edp panel using > an anx9804 parallel lcd to edp convertor. The anx9804 chip is controlled > via an i2c bus which is connected to 2 regular gpio pins. > > Signed-off-by: Hans de Goede Fixed the checkpatch warning (convertor vs converter) and queued, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 1/7] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation
On Wed, Jul 08, 2015 at 05:11:22PM +0100, Peter Griffin wrote: > This patch adds the DT binding documentation for the FDMA constroller > found on STi based chipsets from STMicroelectronics. > > Signed-off-by: Ludovic Barre > Signed-off-by: Peter Griffin > --- > Documentation/devicetree/bindings/dma/st_fdma.txt | 76 > +++ > 1 file changed, 76 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt > > diff --git a/Documentation/devicetree/bindings/dma/st_fdma.txt > b/Documentation/devicetree/bindings/dma/st_fdma.txt > new file mode 100644 > index 000..1ec7470 > --- /dev/null > +++ b/Documentation/devicetree/bindings/dma/st_fdma.txt > @@ -0,0 +1,76 @@ > +* STMicroelectronics Flexible Direct Memory Access Device Tree bindings > + > +The FDMA is a general-purpose direct memory access controller capable of > +supporting 16 independent DMA channels. It accepts up to 32 DMA requests. > +The FDMA is based on a Slim processor which require a firmware. > + > +* FDMA Controller > + > +Required properties: > +- compatible : Should be "st,fdma_mpe31" > +- reg: Should contain DMA registers location and length > +- interrupts : Should contain one interrupt shared by all channel s/channel/channels > +- dma-channels : Number of channels supported by the controller > +- #dma-cells : Must be <3>. any reason three? -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 11/14] drm: bridge: analogix_dp: try force hpd after plug in lookup failed
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
hpd when hpd detect failed.
Changes in v2: None
.../devicetree/bindings/drm/bridge/analogix_dp.txt | 3 ++
.../bindings/video/analogix_dp-rockchip.txt| 1 +
.../devicetree/bindings/video/exynos_dp.txt| 1 +
drivers/gpu/drm/bridge/analogix_dp_core.c | 36 +++---
drivers/gpu/drm/bridge/analogix_dp_core.h | 2 ++
drivers/gpu/drm/bridge/analogix_dp_reg.c | 9 ++
6 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
index 6127018..b043200 100644
--- a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
@@ -40,6 +40,9 @@ Required properties for dp-controller:
*
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
Optional properties for dp-controller:
+ -analogix,need-force-hpd:
+ Indicate driver need force hpd when hpd detect failed, this
+ is used for some eDP screen which don't have hpd signal.
-analogix,hpd-gpio:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug
diff --git a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
index 99fd421..752005e 100644
--- a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
@@ -27,6 +27,7 @@ For the below properties, please refer to Analogix DP binding
document:
- analogix,color-depth (required)
- analogix,link-rate (required)
- analogix,lane-count (required)
+- analogix,need-force-hpd (optional)
- analogix,hpd-gpio (optional)
- video interfaces (optional)
---
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 177506f..ba20416 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -53,6 +53,7 @@ For the below properties, please refer to Analogix DP binding
document:
-analogix,color-depth (required)
-analogix,link-rate (required)
-analogix,lane-count (required)
+ -analogix,need-force-hpd (optional)
-analogix,hpd-gpio (optional)
-video interfaces (optional)
---
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix_dp_core.c
index 1778e0a..99870f7 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
@@ -63,15 +63,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
{
int timeout_loop = 0;
- while (analogix_dp_get_plug_in_status(dp) != 0) {
+ while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+ if (analogix_dp_get_plug_in_status(dp) == 0)
+ return 0;
+
timeout_loop++;
- if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
- dev_err(dp->dev, "failed to get hpd plug status\n");
- return -ETIMEDOUT;
- }
usleep_range(10, 11);
}
+ /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "need-force-hpd" would indicate whether driver need this.
+*/
+ if (!dp->need_force_hpd)
+ return -ETIMEDOUT;
+
+ /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give a force hpd action to
+* set HPD_STATUS manually.
+*/
+ dev_dbg(dp->dev, "failed to get hpd plug status, try to force hpd\n");
+
+ analogix_dp_force_hpd(dp);
+
+ if (analogix_dp_get_plug_in_status(dp) != 0) {
+ dev_err(dp->dev, "failed to get hpd plug in status\n");
+ return -EINVAL;
+ }
+
+ dev_dbg(dp->dev, "success to get plug in status after force hpd\n");
+
return 0;
}
@@ -1272,6 +1295,9 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
if (IS_ERR(dp->reg_base))
return PTR_ERR(dp->reg_base);
+ dp->need_force_hpd =
+ of_property_read_bool(dev->of_node, "analogix,nee
[PATCH v3 02/14] drm: exynos/dp: convert to drm bridge mode
In order to move exynos dp code to bridge directory,
we need to convert driver drm bridge mode first. As
dp driver already have a ptn3460 bridge, so we need
to move ptn bridge to the next bridge of dp bridge.
Signed-off-by: Yakir Yang
---
Changes in v3: None
Changes in v2:
- Take Jingoo Han suggest, just remove my name from author list.
drivers/gpu/drm/exynos/exynos_dp_core.c | 194
drivers/gpu/drm/exynos/exynos_dp_core.h | 1 +
2 files changed, 123 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 562f4a8..2b87406 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -997,59 +997,6 @@ static struct drm_connector_helper_funcs
exynos_dp_connector_helper_funcs = {
.best_encoder = exynos_dp_best_encoder,
};
-/* returns the number of bridges attached */
-static int exynos_drm_attach_lcd_bridge(struct exynos_dp_device *dp,
- struct drm_encoder *encoder)
-{
- int ret;
-
- encoder->bridge = dp->bridge;
- dp->bridge->encoder = encoder;
- ret = drm_bridge_attach(encoder->dev, dp->bridge);
- if (ret) {
- DRM_ERROR("Failed to attach bridge to drm\n");
- return ret;
- }
-
- return 0;
-}
-
-static int exynos_dp_create_connector(struct exynos_drm_display *display,
- struct drm_encoder *encoder)
-{
- struct exynos_dp_device *dp = display_to_dp(display);
- struct drm_connector *connector = &dp->connector;
- int ret;
-
- dp->encoder = encoder;
-
- /* Pre-empt DP connector creation if there's a bridge */
- if (dp->bridge) {
- ret = exynos_drm_attach_lcd_bridge(dp, encoder);
- if (!ret)
- return 0;
- }
-
- connector->polled = DRM_CONNECTOR_POLL_HPD;
-
- ret = drm_connector_init(dp->drm_dev, connector,
-&exynos_dp_connector_funcs,
-DRM_MODE_CONNECTOR_eDP);
- if (ret) {
- DRM_ERROR("Failed to initialize connector with drm\n");
- return ret;
- }
-
- drm_connector_helper_add(connector, &exynos_dp_connector_helper_funcs);
- drm_connector_register(connector);
- drm_mode_connector_attach_encoder(connector, encoder);
-
- if (dp->panel)
- ret = drm_panel_attach(dp->panel, &dp->connector);
-
- return ret;
-}
-
static void exynos_dp_phy_init(struct exynos_dp_device *dp)
{
if (dp->phy)
@@ -1114,23 +1061,126 @@ static void exynos_dp_poweroff(struct exynos_dp_device
*dp)
}
}
-static void exynos_dp_dpms(struct exynos_drm_display *display, int mode)
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct exynos_dp_device *dp,
+ struct drm_encoder *encoder)
+{
+ int ret;
+
+ dp->bridge->next = dp->ptn_bridge;
+ dp->bridge->encoder = encoder;
+ ret = drm_bridge_attach(encoder->dev, dp->bridge);
+ if (ret) {
+ DRM_ERROR("Failed to attach ptn bridge to drm\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
+{
+
+ struct exynos_dp_device *dp = bridge->driver_private;
+ struct drm_encoder *encoder = dp->encoder;
+ struct drm_connector *connector = &dp->connector;
+ int ret;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Parent encoder object not found");
+ return -ENODEV;
+ }
+
+ encoder->bridge = bridge;
+
+ /* Pre-empt DP connector creation if there's a bridge */
+ if (dp->ptn_bridge) {
+ ret = exynos_drm_attach_lcd_bridge(dp, encoder);
+ if (ret)
+ return -ENODEV;
+ }
+
+ connector->polled = DRM_CONNECTOR_POLL_HPD;
+
+ ret = drm_connector_init(dp->drm_dev, connector,
+ &exynos_dp_connector_funcs, DRM_MODE_CONNECTOR_eDP);
+ if (ret) {
+ DRM_ERROR("Failed to initialize connector with drm\n");
+ return ret;
+ }
+
+ drm_connector_helper_add(connector, &exynos_dp_connector_helper_funcs);
+ drm_connector_register(connector);
+ drm_mode_connector_attach_encoder(connector, encoder);
+
+ if (dp->panel)
+ ret = drm_panel_attach(dp->panel, &dp->connector);
+
+ return ret;
+}
+
+static void exynos_dp_bridge_nop(struct drm_bridge *bridge)
+{
+ /* do nothing */
+}
+
+static void exynos_dp_bridge_enable(struct drm_bridge *bridge)
+{
+ struct exynos_dp_device *dp = bridge->driver_private;
+
+ exynos_dp_poweron(dp);
+ dp->dpms_mode = DRM_MODE_DPMS_ON;
+}
+
+static void exynos_dp_bridge_disable(struct drm_bridge *bridge)
+{
+
[PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Take Heiko suggest, add devicetree binding documents.
- Take Thierry Reding suggest, remove sync pol & colorimetry properies
from the new analogix dp driver devicetree binding.
- Update the exist exynos dtsi file with the latest DP DT properies.
Changes in v2: None
.../devicetree/bindings/drm/bridge/analogix_dp.txt | 70 ++
.../devicetree/bindings/video/exynos_dp.txt| 50 ++--
arch/arm/boot/dts/exynos5250-arndale.dts | 10 ++--
arch/arm/boot/dts/exynos5250-smdk5250.dts | 10 ++--
arch/arm/boot/dts/exynos5250-snow.dts | 12 ++--
arch/arm/boot/dts/exynos5250-spring.dts| 12 ++--
arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++--
arch/arm/boot/dts/exynos5420-smdk5420.dts | 10 ++--
arch/arm/boot/dts/exynos5800-peach-pi.dts | 12 ++--
9 files changed, 119 insertions(+), 79 deletions(-)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
new file mode 100644
index 000..6127018
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
@@ -0,0 +1,70 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+ -compatible:
+ platform specific such as:
+* "samsung,exynos5-dp"
+* "rockchip,rk3288-dp"
+ -reg:
+ physical base address of the controller and length
+ of memory mapped region.
+ -interrupts:
+ interrupt combiner values.
+ -clocks:
+ from common clock binding: handle to dp clock.
+ -clock-names:
+ from common clock binding: Shall be "dp".
+ -interrupt-parent:
+ phandle to Interrupt combiner node.
+ -phys:
+ from general PHY binding: the phandle for the PHY device.
+ -phy-names:
+ from general PHY binding: Should be "dp".
+ -analogix,color-space:
+ input video data format.
+ COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
+ -analogix,color-depth:
+ number of bits per colour component.
+ COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
+ -analogix,link-rate:
+ max link rate supported by the eDP controller.
+ LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A,
+ LINK_RATE_5_40GBPS = 0x14
+ -analogix,lane-count:
+ max number of lanes supported by the eDP contoller.
+ LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
+ -port@[X]: SoC specific port nodes with endpoint definitions as defined
+ in Documentation/devicetree/bindings/media/video-interfaces.txt,
+ please refer to the SoC specific binding document:
+ * Documentation/devicetree/bindings/video/exynos_dp.txt
+ *
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+Optional properties for dp-controller:
+ -analogix,hpd-gpio:
+ Hotplug detect GPIO.
+ Indicates which GPIO should be used for hotplug
+ detection
+ -video interfaces: Device node can contain video interface port
+ nodes according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+---
+
+Example:
+
+ dp-controller {
+ compatible = "samsung,exynos5-dp";
+ reg = <0x145b 0x1>;
+ interrupts = <10 3>;
+ interrupt-parent = <&combiner>;
+ clocks = <&clock 342>;
+ clock-names = "dp";
+
+ phys = <&dp_phy>;
+ phy-names = "dp";
+
+ analogix,color-space = <0>;
+ analogix,color-depth = <1>;
+ analogix,link-rate = <0x0a>;
+ analogix,lane-count = <4>;
+ };
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 7a3a9cd..177506f 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -31,28 +31,10 @@ Required properties for dp-controller:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
- -samsung,c
[PATCH v3 07/14] drm: rockchip/dp: add rockchip platform dp driver
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
core driver which name to "dp", and leave "pclk_edp" to rockchip dp platform
driver which name to "pclk".
- Take Heiko suggest, add devicetree binding document.
- Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote
point to get panel node.
- Add the new function point analogix_dp_platdata.get_modes init.
Changes in v2:
- Take Heiko suggest, get panel node with remote-endpoint method,
and create devicetree binding for driver.
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
leave those clock to rockchip dp phy driver.
.../bindings/video/analogix_dp-rockchip.txt| 82 +
drivers/gpu/drm/rockchip/Kconfig | 9 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 389 +
4 files changed, 481 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
diff --git a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
new file mode 100644
index 000..99fd421
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
@@ -0,0 +1,82 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "dp" "pclk"
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: contain a port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- analogix,color-space (required)
+- analogix,color-depth (required)
+- analogix,link-rate (required)
+- analogix,lane-count (required)
+- analogix,hpd-gpio (optional)
+- video interfaces (optional)
+---
+
+Example:
+ dp-controller: dp@ff97 {
+ compatible = "rockchip,rk3288-dp";
+ reg = <0xff97 0x4000>;
+ interrupts = ;
+ clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
+ clock-names = "dp", "pclk";
+ phys = <&dp_phy>;
+ phy-names = "dp";
+
+ rockchip,grf = <&grf>;
+ resets = <&cru 111>;
+ reset-names = "dp";
+
+ hsync-active-high = <0>;
+ vsync-active-high = <0>;
+ interlaced = <0>;
+ analogix,color-space = <0>;
+ analogix,color-depth = <1>;
+ analogix,link-rate = <0x0a>;
+ analogix,lane-count = <4>;
+ status = "disabled";
+
+ ports {
+ edp_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_edp>;
+ };
+ edp_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_edp>;
+ };
+ };
+
+ edp_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_out_panel: endpoint {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>
+ };
+ };
+ };
+ };
+
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..c2ba945 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,12 @
[PATCH v3 10/14] drm: bridge: analogix_dp: add some rk3288 special registers setting
RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.
Signed-off-by: Yakir Yang
---
Changes in v3: None
Changes in v2:
- Fix compile failed dut to phy_pd_addr variable misspell error
drivers/gpu/drm/bridge/analogix_dp_reg.c | 76
drivers/gpu/drm/bridge/analogix_dp_reg.h | 12 +
2 files changed, 60 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix_dp_reg.c
index cc5cdbf..a0fc1fb 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix_dp_reg.c
@@ -15,6 +15,8 @@
#include
#include
+#include
+
#include "analogix_dp_core.h"
#include "analogix_dp_reg.h"
@@ -72,6 +74,14 @@ void analogix_dp_init_analog_param(struct analogix_dp_device
*dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
+ if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+ writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+ writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
+ writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
+ writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
+ writel(0x22, dp->reg_base + ANALOGIX_DP_PLL_REG_5);
+ }
+
reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);
@@ -206,81 +216,85 @@ void analogix_dp_set_analog_power_down(struct
analogix_dp_device *dp,
bool enable)
{
u32 reg;
+ u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+
+ if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+ phy_pd_addr = ANALOGIX_DP_PD;
switch (block) {
case AUX_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= AUX_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~AUX_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH0_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH0_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH0_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH1_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH1_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH1_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH2_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH2_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH2_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH3_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ re
[PATCH v3 14/14] drm: bridge/analogix_dp: add edid modes parse in get_modes method
Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Add edid modes parse support
Changes in v2: None
drivers/gpu/drm/bridge/analogix_dp_core.c | 17 +++-
drivers/gpu/drm/bridge/analogix_dp_core.h | 45 ---
2 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix_dp_core.c
index 052b9b3..83698c6 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
@@ -111,7 +111,7 @@ static unsigned char
analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
static int analogix_dp_read_edid(struct analogix_dp_device *dp)
{
- unsigned char edid[EDID_BLOCK_LENGTH * 2];
+ unsigned char *edid = dp->edid;
unsigned int extend_block = 0;
unsigned char sum;
unsigned char test_vector;
@@ -915,12 +915,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to disable the panel\n");
}
- ret = analogix_dp_handle_edid(dp);
- if (ret) {
- dev_err(dp->dev, "unable to handle edid\n");
- return;
- }
-
ret = analogix_dp_set_link_train(dp, dp->video_info->max_lane_count,
dp->video_info->max_link_rate);
if (ret) {
@@ -976,8 +970,17 @@ static int analogix_dp_get_modes(struct drm_connector
*connector)
{
struct analogix_dp_device *dp = connector_to_dp(connector);
struct analogix_dp_plat_data *plat_data = dp->plat_data;
+ struct edid *edid = (struct edid *)dp->edid;
int num_modes = 0;
+ if (analogix_dp_handle_edid(dp)) {
+ dev_err(dp->dev, "unable to handle edid\n");
+ return -EINVAL;
+ }
+
+ drm_mode_connector_update_edid_property(connector, edid);
+ num_modes += drm_add_edid_modes(connector, edid);
+
if (plat_data && plat_data->panel)
num_modes += drm_panel_get_modes(plat_data->panel);
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix_dp_core.h
index 2405155..950b6ca 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix_dp_core.h
@@ -20,6 +20,28 @@
#define MAX_CR_LOOP 5
#define MAX_EQ_LOOP 5
+/* I2C EDID Chip ID, Slave Address */
+#define I2C_EDID_DEVICE_ADDR 0x50
+#define I2C_E_EDID_DEVICE_ADDR 0x30
+
+#define EDID_BLOCK_LENGTH 0x80
+#define EDID_HEADER_PATTERN0x00
+#define EDID_EXTENSION_FLAG0x7e
+#define EDID_CHECKSUM 0x7f
+
+/* DP_MAX_LANE_COUNT */
+#define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
+#define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
+
+/* DP_LANE_COUNT_SET */
+#define DPCD_LANE_COUNT_SET(x) ((x) & 0x1f)
+
+/* DP_TRAINING_LANE0_SET */
+#define DPCD_PRE_EMPHASIS_SET(x) (((x) & 0x3) << 3)
+#define DPCD_PRE_EMPHASIS_GET(x) (((x) >> 3) & 0x3)
+#define DPCD_VOLTAGE_SWING_SET(x) (((x) & 0x3) << 0)
+#define DPCD_VOLTAGE_SWING_GET(x) (((x) >> 0) & 0x3)
+
enum link_rate_type {
LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
@@ -161,6 +183,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolneed_force_hpd;
+ unsigned char edid[EDID_BLOCK_LENGTH * 2];
struct analogix_dp_plat_data *plat_data;
};
@@ -260,26 +283,4 @@ void analogix_dp_config_video_slave_mode(struct
analogix_dp_device *dp);
void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
-/* I2C EDID Chip ID, Slave Address */
-#define I2C_EDID_DEVICE_ADDR 0x50
-#define I2C_E_EDID_DEVICE_ADDR 0x30
-
-#define EDID_BLOCK_LENGTH 0x80
-#define EDID_HEADER_PATTERN0x00
-#define EDID_EXTENSION_FLAG0x7e
-#define EDID_CHECKSUM 0x7f
-
-/* DP_MAX_LANE_COUNT */
-#define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
-#define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
-
-/* DP_LANE_COUNT_SET */
-#define DPCD_LANE_COUNT_SET(x) ((x) & 0x1f)
-
-/* DP_TRAINING_LANE0_SET */
-#define DPCD_PRE_EMPHASIS_SET(x) (((x) & 0x3) << 3)
-#define DPCD_PRE_EMPHASIS_GET(x) (((x) >> 3) & 0x3)
-#define DPCD_VOLTAGE_SWING_SET(x) (((x) & 0x3) << 0)
-#define DPCD_VOLTAGE_SWING_GET(x) (((x) >> 0) & 0x3)
-
#endi
[PATCH v3 13/14] drm: bridge/analogix_dp: move hpd detect to connector detect function
Signed-off-by: Yakir Yang
---
Changes in v3:
- move dp hpd detect to connector detect function.
Changes in v2: None
drivers/gpu/drm/bridge/analogix_dp_core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix_dp_core.c
index 75dd44a..052b9b3 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
@@ -915,12 +915,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to disable the panel\n");
}
- ret = analogix_dp_detect_hpd(dp);
- if (ret) {
- /* Cable has been disconnected, we're done */
- return;
- }
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp->dev, "unable to handle edid\n");
@@ -953,6 +947,12 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
static enum drm_connector_status analogix_dp_detect(
struct drm_connector *connector, bool force)
{
+ struct analogix_dp_device *dp = connector_to_dp(connector);
+
+ if (analogix_dp_detect_hpd(dp))
+ /* Cable has been disconnected, we're done */
+ return connector_status_disconnected;
+
return connector_status_connected;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 12/14] drm: bridge/analogix_dp: expand the delay time for hpd detect
Some edp screen with no hpd signal would need some delay time to ensure that screen would be ready for work, so we can expand the delay time in hpd detect function, it works prefectly on my rk3288 sdk board. Signed-off-by: Yakir Yang --- Changes in v3: None Changes in v2: None drivers/gpu/drm/bridge/analogix_dp_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix_dp_core.c index 99870f7..75dd44a 100644 --- a/drivers/gpu/drm/bridge/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix_dp_core.c @@ -68,7 +68,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device *dp) return 0; timeout_loop++; - usleep_range(10, 11); + usleep_range(100, 110); } /* -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 08/14] phy: Add driver for rockchip Display Port PHY
Signed-off-by: Yakir Yang
---
Changes in v3:
- Take Heiko suggest, add rockchip dp phy driver,
collect the phy clocks and power control.
Changes in v2: None
.../devicetree/bindings/phy/rockchip-dp-phy.txt| 26 +++
drivers/phy/Kconfig| 7 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-rockchip-dp.c | 185 +
4 files changed, 219 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
create mode 100644 drivers/phy/phy-rockchip-dp.c
diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..5de1088
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,26 @@
+Rockchip Soc Seroes Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+
+- reg : a list of registers used by phy driver
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "sclk_dp" "sclk_dp_24m"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: phy@ff770274 {
+ compatilble = "rockchip,rk3288-dp-phy";
+ reg = <0xff770274 4>;
+ rockchip,grf = <&grf>;
+ clocks = <&cru SCLK_EDP_24M>;
+ clock-names = "24m";
+ #phy-cells = <0>;
+}
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 6b8dd16..da00440 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -297,6 +297,13 @@ config PHY_ROCKCHIP_USB
help
Enable this to support the Rockchip USB 2.0 PHY.
+config PHY_ROCKCHIP_DP
+ tristate "Rockchip Display Port PHY Driver"
+ depends on ARCH_ROCKCHIP && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the Rockchip Display Port PHY.
+
config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f344e1b..35e3ce6 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -33,6 +33,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..4759111
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,185 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GRF_SOC_CON12 0x0274
+#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
+
+#define DP_PHY_SIDDQ_WRITE_EN BIT(21)
+#define DP_PHY_SIDDQ_ON 0
+#define DP_PHY_SIDDQ_OFFBIT(5)
+
+struct rockchip_dp_phy {
+ struct device *dev;
+ struct regmap *grf;
+ void __iomem *regs;
+ struct clk *phy_24m;
+};
+
+static int rockchip_dp_phy_clk_enable(struct rockchip_dp_phy *dp)
+{
+ int ret = 0;
+
+ ret = clk_set_rate(dp->phy_24m, 2400);
+ if (ret < 0) {
+ dev_err(dp->dev, "cannot set clock phy_24m %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(dp->phy_24m);
+ if (ret < 0) {
+ dev_err(dp->dev, "cannot enable clock phy_24m %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int rockchip_dp_phy_clk_disable(struct rockchip_dp_phy *dp)
+{
+ clk_disable_unprepare(dp->phy_24m);
+
+ return 0;
+}
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+ struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+
+ if (enable) {
+ rockchip_dp_phy_clk_enable(dp);
+ writel(DP_PHY_SIDDQ_WRITE_EN | DP_PHY_SIDDQ_ON, dp->regs);
+ } else {
+ rockchip_dp_phy_clk_disable(dp);
+ writel(DP_PHY_SIDDQ_WRITE_EN | DP_PHY_SIDDQ_OFF, dp->regs);
+ }
+
[PATCH v3 05/14] drm: bridge/analogix_dp: fix link_rate & lane_count bug
link_rate and lane_count already configed in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.
Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
the DT property value directly, but we can take those as hardware limite.
For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
so DT property would like "link-rate = 0x0a" "lane-count = 4".
Changes in v2: None
drivers/gpu/drm/bridge/analogix_dp_core.c | 16
drivers/gpu/drm/bridge/analogix_dp_core.h | 9 +
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix_dp_core.c
index 480cc13..1778e0a 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
@@ -635,6 +635,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct
analogix_dp_device *dp,
/*
* For DP rev.1.1, Maximum link rate of Main Link lanes
* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+* For DP rev.1.2, Maximum link rate of Main Link lanes
+* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
*/
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, &data);
*bandwidth = data;
@@ -668,7 +670,8 @@ static void analogix_dp_init_training(struct
analogix_dp_device *dp,
analogix_dp_get_max_rx_lane_count(dp, &dp->link_train.lane_count);
if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
- (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+ (dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
+ (dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
dp->link_train.link_rate);
dp->link_train.link_rate = LINK_RATE_1_62GBPS;
@@ -901,8 +904,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
return;
}
- ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-dp->video_info->link_rate);
+ ret = analogix_dp_set_link_train(dp, dp->video_info->max_lane_count,
+dp->video_info->max_link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -912,9 +915,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);
- analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
- analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
@@ -1198,13 +1198,13 @@ static struct video_info
*analogix_dp_dt_parse_pdata(struct device *dev)
}
if (of_property_read_u32(dp_node, "analogix,link-rate",
-&dp_video_config->link_rate)) {
+&dp_video_config->max_link_rate)) {
dev_err(dev, "failed to get link-rate\n");
return ERR_PTR(-EINVAL);
}
if (of_property_read_u32(dp_node, "analogix,lane-count",
-&dp_video_config->lane_count)) {
+&dp_video_config->max_lane_count)) {
dev_err(dev, "failed to get lane-count\n");
return ERR_PTR(-EINVAL);
}
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix_dp_core.h
index 2cefde9..941b34f 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix_dp_core.h
@@ -21,8 +21,9 @@
#define MAX_EQ_LOOP 5
enum link_rate_type {
- LINK_RATE_1_62GBPS = 0x06,
- LINK_RATE_2_70GBPS = 0x0a
+ LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
+ LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
+ LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
};
enum link_lane_count_type {
@@ -128,8 +129,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
- enum link_rate_type link_rate;
- enum link_lane_count_type lane_count;
+ enum link_rate_type max_link_rate;
+ enum link_lane_count_type max_lane_count;
};
struct link_train {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 09/14] drm: bridge/analogix_dp: add platform device type support
Signed-off-by: Yakir Yang
---
Changes in v3: None
Changes in v2:
- Add GNU license v2 declared and samsung copyright
drivers/gpu/drm/exynos/analogix_dp-exynos.c | 1 +
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 1 +
include/drm/bridge/analogix_dp.h| 16
3 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/exynos/analogix_dp-exynos.c
b/drivers/gpu/drm/exynos/analogix_dp-exynos.c
index 17da2c8..b160159 100644
--- a/drivers/gpu/drm/exynos/analogix_dp-exynos.c
+++ b/drivers/gpu/drm/exynos/analogix_dp-exynos.c
@@ -220,6 +220,7 @@ static int exynos_dp_bind(struct device *dev, struct device
*master, void *data)
dp->dev = dev;
dp->drm_dev = drm_dev;
+ dp->plat_data.dev_type = EXYNOS_DP;
dp->plat_data.power_on = exynos_dp_poweron;
dp->plat_data.power_off = exynos_dp_poweroff;
dp->plat_data.get_modes = exynos_dp_get_modes;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index cebff9e..f2c5c26 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -267,6 +267,7 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
return ret;
}
+ dp->plat_data.dev_type = RK3288_DP;
dp->plat_data.attach = NULL;
dp->plat_data.get_modes = NULL;
dp->plat_data.power_on = rockchip_dp_poweron;
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 8b4ffad..7209a64 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -1,9 +1,25 @@
+/*
+ * Analogix Core DP (Display Port) interface driver.
+ *
+ * Copyright (C) 2012 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
#ifndef _ANALOGIX_DP_H_
#define _ANALOGIX_DP_H_
#include
+enum analogix_dp_devtype {
+ EXYNOS_DP,
+ RK3288_DP,
+};
+
struct analogix_dp_plat_data {
+ enum analogix_dp_devtype dev_type;
struct drm_panel *panel;
int (*power_on)(struct analogix_dp_plat_data *);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 04/14] drm: bridge/analogix_dp: dynamic parse sync_pol & interlace & colorimetry
Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.
But presumably Exynos still relaies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Take Thierry Reding suggest, dynamic parse video timing info from
struct drm_display_mode and struct drm_display_info.
Changes in v2: None
drivers/gpu/drm/bridge/analogix_dp_core.c | 50 --
drivers/gpu/drm/exynos/analogix_dp-exynos.c | 65 ++---
2 files changed, 89 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix_dp_core.c
index 6c15e20..480cc13 100644
--- a/drivers/gpu/drm/bridge/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
@@ -1110,11 +1110,40 @@ static void analogix_dp_bridge_disable(struct
drm_bridge *bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+ struct drm_display_mode *orig_mode,
+ struct drm_display_mode *mode)
+{
+ struct analogix_dp_device *dp = bridge->driver_private;
+ struct video_info *video_info = dp->video_info;
+ int vic;
+
+ /* interlaces & hsync pol & vsync pol */
+ video_info->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+ video_info->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+ video_info->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+ /* dynamic_range & colorimetry */
+ vic = drm_match_cea_mode(mode);
+ if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+ (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+ video_info->dynamic_range = CEA;
+ video_info->ycbcr_coeff = COLOR_YCBCR601;
+ } else if (vic) {
+ video_info->dynamic_range = CEA;
+ video_info->ycbcr_coeff = COLOR_YCBCR709;
+ } else {
+ video_info->dynamic_range = VESA;
+ video_info->ycbcr_coeff = COLOR_YCBCR709;
+ }
+}
+
static const struct drm_bridge_funcs analogix_dp_bridge_funcs = {
.enable = analogix_dp_bridge_enable,
.disable = analogix_dp_bridge_disable,
.pre_enable = analogix_dp_bridge_nop,
.post_disable = analogix_dp_bridge_nop,
+ .mode_set = analogix_dp_bridge_mode_set,
.attach = analogix_dp_bridge_attach,
};
@@ -1156,33 +1185,12 @@ static struct video_info
*analogix_dp_dt_parse_pdata(struct device *dev)
if (!dp_video_config)
return ERR_PTR(-ENOMEM);
- dp_video_config->h_sync_polarity =
- of_property_read_bool(dp_node, "hsync-active-high");
-
- dp_video_config->v_sync_polarity =
- of_property_read_bool(dp_node, "vsync-active-high");
-
- dp_video_config->interlaced =
- of_property_read_bool(dp_node, "interlaced");
-
if (of_property_read_u32(dp_node, "analogix,color-space",
&dp_video_config->color_space)) {
dev_err(dev, "failed to get color-space\n");
return ERR_PTR(-EINVAL);
}
- if (of_property_read_u32(dp_node, "analogix,dynamic-range",
-&dp_video_config->dynamic_range)) {
- dev_err(dev, "failed to get dynamic-range\n");
- return ERR_PTR(-EINVAL);
- }
-
- if (of_property_read_u32(dp_node, "analogix,ycbcr-coeff",
-&dp_video_config->ycbcr_coeff)) {
- dev_err(dev, "failed to get ycbcr-coeff\n");
- return ERR_PTR(-EINVAL);
- }
-
if (of_property_read_u32(dp_node, "analogix,color-depth",
&dp_video_config->color_depth)) {
dev_err(dev, "failed to get color-depth\n");
diff --git a/drivers/gpu/drm/exynos/analogix_dp-exynos.c
b/drivers/gpu/drm/exynos/analogix_dp-exynos.c
index d5631c2..17da2c8 100644
--- a/drivers/gpu/drm/exynos/analogix_dp-exynos.c
+++ b/drivers/gpu/drm/exynos/analogix_dp-exynos.c
@@ -26,11 +26,17 @@
#include
#include "exynos_drm_drv.h"
-#define plat_data_to_dp(pd) \
- container_of(pd, struct exynos_dp_device, plat_data)
+#define to_dp(nm) container_of(nm, struct exynos_dp_device, nm)
+
+struct video_info {
+ bool h_sync_polarity;
+ bool v_sync_polarity;
+ bool interlaced;
+};
struct exynos_dp_device {
struct exynos_drm_display display;
+ struct video_info video_info;
struct drm_bridge *ptn_bridge;
struct drm_device *drm_dev;
struct device *dev;
@@ -42,7 +48,7 @@ struct exynos_dp_device {
int exynos_dp_crtc_clock_enable(struct anal
Re: [PATCH v7 0/9] Fixes and new clocks support for Mediatek MT8173
Hi Dan, On Fri, Aug 14, 2015 at 12:01:06PM +0800, Daniel Kurtz wrote: > On Tue, Aug 11, 2015 at 12:43 PM, Daniel Kurtz wrote: > > Hi James, > > > > On Mon, Aug 10, 2015 at 5:50 PM, James Liao > > wrote: > >> This patchset is based on 4.2-rc2 and [1], and contains minor fixes and > >> subsystem clocks support for Mediatek MT8173. > >> > >> The previous reviews can be found in [2]. > >> > >> changes since v6: > >> - Use DUMMY_RATE (0) instead of typical rate for clocks that we don't care > >> and not controlled in CCF. > > > > For the whole series: > > Reviewed-by: Daniel Kurtz > > Hi Sascha, > > Are you happy with these patches now? Yes. Acked-by: Sascha Hauer Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 01/14] drm: exynos/dp: fix code style
After run "checkpatch.pl -f --subjective" command, I see there
are lots of alignment problem in exynos_dp driver, so let just
fix them.
Signed-off-by: Yakir Yang
---
Changes in v3: None
Changes in v2:
- Take Joe Preches advise, improved commit message more readable, and
avoid using some uncommon style like bellow:
- retval = exynos_dp_read_bytes_from_i2c(...
...)
+ retval =
+ exynos_dp_read_bytes_from_i2c(..);
drivers/gpu/drm/exynos/exynos_dp_core.c | 219
drivers/gpu/drm/exynos/exynos_dp_core.h | 53
drivers/gpu/drm/exynos/exynos_dp_reg.c | 100 +++
3 files changed, 182 insertions(+), 190 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 172b800..562f4a8 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -114,8 +114,8 @@ static int exynos_dp_read_edid(struct exynos_dp_device *dp)
/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = exynos_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
- EDID_EXTENSION_FLAG,
- &extend_block);
+ EDID_EXTENSION_FLAG,
+ &extend_block);
if (retval)
return retval;
@@ -123,10 +123,11 @@ static int exynos_dp_read_edid(struct exynos_dp_device
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");
/* Read EDID data */
- retval = exynos_dp_read_bytes_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
- EDID_HEADER_PATTERN,
- EDID_BLOCK_LENGTH,
- &edid[EDID_HEADER_PATTERN]);
+ retval = exynos_dp_read_bytes_from_i2c(
+ dp, I2C_EDID_DEVICE_ADDR,
+ EDID_HEADER_PATTERN,
+ EDID_BLOCK_LENGTH,
+ &edid[EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -138,11 +139,11 @@ static int exynos_dp_read_edid(struct exynos_dp_device
*dp)
}
/* Read additional EDID data */
- retval = exynos_dp_read_bytes_from_i2c(dp,
- I2C_EDID_DEVICE_ADDR,
- EDID_BLOCK_LENGTH,
- EDID_BLOCK_LENGTH,
- &edid[EDID_BLOCK_LENGTH]);
+ retval = exynos_dp_read_bytes_from_i2c(
+ dp, I2C_EDID_DEVICE_ADDR,
+ EDID_BLOCK_LENGTH,
+ EDID_BLOCK_LENGTH,
+ &edid[EDID_BLOCK_LENGTH]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -154,24 +155,22 @@ static int exynos_dp_read_edid(struct exynos_dp_device
*dp)
}
exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
- &test_vector);
+ &test_vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
- exynos_dp_write_byte_to_dpcd(dp,
- DP_TEST_EDID_CHECKSUM,
+ exynos_dp_write_byte_to_dpcd(
+ dp, DP_TEST_EDID_CHECKSUM,
edid[EDID_BLOCK_LENGTH + EDID_CHECKSUM]);
- exynos_dp_write_byte_to_dpcd(dp,
- DP_TEST_RESPONSE,
+ exynos_dp_write_byte_to_dpcd(
+ dp, DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
}
} else {
dev_info(dp->dev, "EDID data does not include any
extensions.\n");
/* Read EDID data */
- retval = exynos_dp_read_bytes_from_i2c(dp,
- I2C_EDID_DEVICE_ADDR,
- EDID_HEADER_PATTERN,
- EDID_BLOCK_LENGTH,
- &edid[EDID_HEADER_PATTERN]);
+ retval = exynos_dp_read_bytes_from_i2c(
+ dp, I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+ EDID_BLOCK_LENGTH, &edid[EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -182,16 +181,15 @@ static
[PATCH v3 0/14] Add Analogix Core Display Port Driver
Hi all, The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller share the same IP, so a lot of parts can be re-used. I split the common code into bridge directory, then rk3288 and exynos only need to keep some platform code. Cause I can't find the exact IP name of exynos dp controller, so I decide to name dp core driver with "analogix" which I find in rk3288 eDP TRM ;) Beyond that, there are three light registers setting differents bewteen exynos and rk3288. 1. RK3288 have five special pll resigters which not indicata in exynos dp controller. 2. The address of DP_PHY_PD(dp phy power manager register) are different between rk3288 and exynos. 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug register). I have verified this series on two kinds of rockchip platform board, one is rk3288 sdk board which connect with a 2K display port monitor, the other is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2", both of them works rightlly. I haven't verified the dp function on samsung platform, cause I haven't got exynos boards. I can only ensure that there are no build error on samsung platform, wish some samsung guys help to test. ;) Thanks, - Yakir Changes in v3: - Take Thierry Reding suggest, move exynos's video_timing code to analogix_dp-exynos platform driver, add get_modes method to struct analogix_dp_plat_data. - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*". - Take Thierry Reding suggest, dynamic parse video timing info from struct drm_display_mode and struct drm_display_info. - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to the DT property value directly, but we can take those as hardware limite. For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would like "link-rate = 0x0a" "lane-count = 4". - Take Heiko suggest, add devicetree binding documents. - Take Thierry Reding suggest, remove sync pol & colorimetry properies from the new analogix dp driver devicetree binding. - Update the exist exynos dtsi file with the latest DP DT properies. - Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp core driver which name to "dp", and leave "pclk_edp" to rockchip dp platform driver which name to "pclk". - Take Heiko suggest, add devicetree binding document. - Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote point to get panel node. - Add the new function point analogix_dp_platdata.get_modes init. - Take Heiko suggest, add rockchip dp phy driver, collect the phy clocks and power control. - Add "analogix,need-force-hpd" to indicate whether driver need foce hpd when hpd detect failed. - move dp hpd detect to connector detect function. - Add edid modes parse support Changes in v2: - Take Joe Preches advise, improved commit message more readable, and avoid using some uncommon style like bellow: - retval = exynos_dp_read_bytes_from_i2c(... ...) + retval = + exynos_dp_read_bytes_from_i2c(..); - Take Jingoo Han suggest, just remove my name from author list. - Take Jingoo Han suggest, remove new copyright - Fix compiled failed dut to analogix_dp_device misspell - Take Heiko suggest, get panel node with remote-endpoint method, and create devicetree binding for driver. - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m", leave those clock to rockchip dp phy driver. - Add GNU license v2 declared and samsung copyright - Fix compile failed dut to phy_pd_addr variable misspell error Yakir Yang (14): drm: exynos/dp: fix code style drm: exynos/dp: convert to drm bridge mode drm: bridge: analogix_dp: split exynos dp driver to bridge dir drm: bridge/analogix_dp: dynamic parse sync_pol & interlace & colorimetry drm: bridge/analogix_dp: fix link_rate & lane_count bug Documentation: drm/bridge: add document for analogix_dp drm: rockchip/dp: add rockchip platform dp driver phy: Add driver for rockchip Display Port PHY drm: bridge/analogix_dp: add platform device type support drm: bridge: analogix_dp: add some rk3288 special registers setting drm: bridge: analogix_dp: try force hpd after plug in lookup failed drm: bridge/analogix_dp: expand the delay time for hpd detect drm: bridge/analogix_dp: move hpd detect to connector detect function drm: bridge/analogix_dp: add edid modes parse in get_modes method .../devicetree/bindings/drm/bridge/analogix_dp.txt | 73 + .../devicetree/bindings/phy/rockchip-dp-phy.txt| 26 + .../bindings/video/analogix_dp-rockchip.txt| 83 ++ .../devicetree/bindings/video/exynos_dp.txt| 51 +- arch/arm/boot/dts/exynos5250-arndale.dts | 10 +- arch/arm/boot/dts/exynos5250-smdk5250.dts | 10 +- arch/arm/boot/dts/exynos5250-snow.dts | 12 +- arch/arm/
[PATCH v3 4/5] mailbox: Add generic mechanism for testing Mailbox Controllers
This particular Client implementation uses shared memory in order
to pass messages between Mailbox users; however, it can be easily
hacked to support any type of Controller.
Signed-off-by: Lee Jones
---
drivers/mailbox/Kconfig| 7 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/mailbox-test.c | 361 +
3 files changed, 370 insertions(+)
create mode 100644 drivers/mailbox/mailbox-test.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 2cc4c39..7720bde 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -77,4 +77,11 @@ config STI_MBOX
Mailbox implementation for STMicroelectonics family chips with
hardware for interprocessor communication.
+config MAILBOX_TEST
+ tristate "Mailbox Test Client"
+ depends on OF
+ help
+ Test client to help with testing new Controller driver
+ implementations.
+
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 7cb4766..92435ef 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -2,6 +2,8 @@
obj-$(CONFIG_MAILBOX) += mailbox.o
+obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
+
obj-$(CONFIG_ARM_MHU) += arm_mhu.o
obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
diff --git a/drivers/mailbox/mailbox-test.c b/drivers/mailbox/mailbox-test.c
new file mode 100644
index 000..cac1ba2
--- /dev/null
+++ b/drivers/mailbox/mailbox-test.c
@@ -0,0 +1,361 @@
+/*
+ * Copyright (C) 2015 ST Microelectronics
+ *
+ * Author: Lee Jones
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MBOX_MAX_SIG_LEN 8
+#define MBOX_MAX_MSG_LEN 128
+#define MBOX_BYTES_PER_LINE16
+#define MBOX_HEXDUMP_LINE_LEN ((MBOX_BYTES_PER_LINE * 4) + 2)
+#define MBOX_HEXDUMP_MAX_LEN (MBOX_HEXDUMP_LINE_LEN *\
+(MBOX_MAX_MSG_LEN / MBOX_BYTES_PER_LINE))
+
+static struct dentry *root_debugfs_dir;
+
+struct mbox_test_device {
+ struct device *dev;
+ void __iomem*mmio;
+ struct mbox_chan*tx_channel;
+ struct mbox_chan*rx_channel;
+ char*rx_buffer;
+ char*signal;
+ char*message;
+ spinlock_t lock;
+};
+
+static ssize_t mbox_test_signal_write(struct file *filp,
+ const char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ struct mbox_test_device *tdev = filp->private_data;
+ int ret;
+
+ if (!tdev->tx_channel) {
+ dev_err(tdev->dev, "Channel cannot do Tx\n");
+ return -EINVAL;
+ }
+
+ if (count > MBOX_MAX_SIG_LEN) {
+ dev_err(tdev->dev,
+ "Signal length %d greater than max allowed %d\n",
+ count, MBOX_MAX_SIG_LEN);
+ return -EINVAL;
+ }
+
+ tdev->signal = kzalloc(MBOX_MAX_SIG_LEN, GFP_KERNEL);
+ if (!tdev->signal)
+ return -ENOMEM;
+
+ ret = copy_from_user(tdev->signal, userbuf, count);
+ if (ret) {
+ kfree(tdev->signal);
+ return -EFAULT;
+ }
+
+ return ret < 0 ? ret : count;
+}
+
+static const struct file_operations mbox_test_signal_ops = {
+ .write = mbox_test_signal_write,
+ .open = simple_open,
+ .llseek = generic_file_llseek,
+};
+
+static ssize_t mbox_test_message_write(struct file *filp,
+ const char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ struct mbox_test_device *tdev = filp->private_data;
+ void *data;
+ int ret;
+
+ if (!tdev->tx_channel) {
+ dev_err(tdev->dev, "Channel cannot do Tx\n");
+ return -EINVAL;
+ }
+
+ if (count > MBOX_MAX_MSG_LEN) {
+ dev_err(tdev->dev,
+ "Message length %d greater than max allowed %d\n",
+ count, MBOX_MAX_MSG_LEN);
+ return -EINVAL;
+ }
+
+ tdev->message = kzalloc(MBOX_MAX_MSG_LEN, GFP_KERNEL);
+ if (!tdev->message)
+ return -ENOMEM;
+
+ ret = copy_from_user(tdev->message, userbuf, count);
+ if (ret) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ /*
+* A separate signal is only of use if there is
+* MMIO to subsequently pass the message through
+*/
+ if (tdev->mmio && tdev->signal) {
+ print_
[PATCH v3 1/5] mailbox: dt: Supply bindings for ST's Mailbox IP
Signed-off-by: Lee Jones
---
.../devicetree/bindings/mailbox/sti-mailbox.txt| 52 ++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
new file mode 100644
index 000..9fb4400
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
@@ -0,0 +1,52 @@
+ST Microelectronics Mailbox Driver
+
+Each ST Mailbox IP currently consists of 4 instances of 32 channels. Messages
+are passed between Application and Remote processors using shared memory.
+
+Controller
+--
+
+Required properties:
+- compatible : Should be "st,stih407-mailbox"
+- reg : Offset and length of the device's register set
+- mbox-name: Name of the mailbox
+- #mbox-cells: : Must be 2
+ <&phandle instance channel direction>
+ phandle : Label name of controller
+ instance : Instance number
+ channel : Channel number
+
+Optional properties
+- interrupts : Contains the IRQ line for a Rx mailbox
+- tx-only : Denotes Mailbox cannot receive messages
+
+Example:
+
+mailbox0: mailbox@0 {
+ compatible = "st,stih407-mailbox";
+ reg = <0x08f0 0x1000>;
+ interrupts = ;
+ #mbox-cells = <2>;
+ mbox-name = "a9";
+};
+
+Client
+--
+
+Required properties:
+- compatible : Many (See the client docs)
+- reg : Shared (between Application and Remote) memory address
+- mboxes : Standard property to specify a Mailbox (See
./mailbox.txt)
+ Cells must match 'mbox-cells' (See Controller docs
above)
+
+Optional properties
+- mbox-names : Name given to channels seen in the 'mboxes' property.
+
+Example:
+
+mailbox_test {
+ compatible = "mailbox_test";
+ reg = <0x[shared_memory_address], [shared_memory_size]>;
+ mboxes = <&mailbox2 0 1>, <&mailbox0 2 1>;
+ mbox-names = "tx", "rx";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
