[PATCH v4 4/4] ata: Removing NCQ support from the APM X-Gene SoC AHCI SATA Host Controller driver.
This patch removes the NCQ support from the APM X-Gene SoC AHCI
Host Controller driver as it doesn't support it.
Signed-off-by: Loc Ho l...@apm.com
Signed-off-by: Suman Tripathi stripa...@apm.com
---
drivers/ata/ahci_xgene.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 1d48371..4496ddf 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -310,8 +310,8 @@ static struct ata_port_operations xgene_ahci_ops = {
};
static const struct ata_port_info xgene_ahci_port_info = {
- AHCI_HFLAGS(AHCI_HFLAG_NO_PMP | AHCI_HFLAG_YES_NCQ),
- .flags = AHCI_FLAG_COMMON | ATA_FLAG_NCQ,
+ AHCI_HFLAGS(AHCI_HFLAG_NO_PMP | AHCI_HFLAG_NO_NCQ),
+ .flags = AHCI_FLAG_COMMON,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
.port_ops = xgene_ahci_ops,
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/4] ata: Fix the watermark threshold for the APM X-Gene SATA host controller driver.
As per SATA IO specification, when Host sends HOLD, the device takes about 20DW latency to reply to HOLDA. In some case, device doesn't response to HOLDA over 20DW and causes FIFO goes into over flow condition. Due to this condition, device enumerations fails with those devices. This patch adjust the watermark FIFO by increasing the FIFO depth from 0x16(default) to 0x30 to address this issue. Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com --- drivers/ata/ahci_xgene.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c index 77c89bf..03b6b0f 100644 --- a/drivers/ata/ahci_xgene.c +++ b/drivers/ata/ahci_xgene.c @@ -67,6 +67,9 @@ #define PORTAXICFG 0x00bc #define PORTAXICFG_OUTTRANS_SET(dst, src) \ (((dst) ~0x00f0) | (((u32)(src) 0x14) 0x00f0)) +#define PORTRANSCFG0x00c8 +#define PORTRANSCFG_RXWM_SET(dst, src) \ + (((dst) ~0x007f) | (((u32)(src)) 0x007f)) /* SATA host controller AXI CSR */ #define INT_SLV_TMOMASK0x0010 @@ -176,6 +179,10 @@ static void xgene_ahci_set_phy_cfg(struct xgene_ahci_context *ctx, int channel) val = PORTAXICFG_OUTTRANS_SET(val, 0xe); /* Set outstanding */ writel(val, mmio + PORTAXICFG); readl(mmio + PORTAXICFG); /* Force a barrier */ + /* Set the watermark threshold of the receive FIFO */ + val = readl(mmio + PORTRANSCFG); + val = PORTRANSCFG_RXWM_SET(val, 0x30); + writel(val, mmio + PORTRANSCFG); } /** -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/4]ata: Fixes related to APM X-Gene SATA host controller driver.
This patch set contains a couple of fixes related to APM X-Gene SATA controller driver. v2 Change: 1. Drop the Link down retry patch from this patch set. v4 Change: 1. Drop the patch to fix the csr-mask in dts for PHY clock node of SATA Host Controller 1. 2. Add the patch to correct the OOB tunning parameters for the COMINIT/COMWAKE parameters. 3. Add the patch to remove the NCQ support from the APM X-Gene AHCI SATA Host controller driver. 4. Add the patch to remove the clock and PHY reference nodes from the APM X-Gene Host controller dts node. Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com --- Suman Tripathi (4): ata: Fix the watermark threshold for the APM X-Gene SATA host controller driver. arm64: Remove the clock and PHY reference from the APM X-Gene SoC AHCI SATA Host controller dts node. ata: Use correct OOB tunning parameters for APM X-Gene SoC AHCI SATA Host controller driver. ata: Removing NCQ support from the APM X-Gene SoC AHCI SATA Host Controller driver. arch/arm64/boot/dts/apm-storm.dtsi | 92 -- drivers/ata/ahci_xgene.c | 17 --- 2 files changed, 12 insertions(+), 97 deletions(-) -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/4] ata: Use correct OOB tunning parameters for APM X-Gene SoC AHCI SATA Host controller driver.
APM X-Gene SoC AHCI SATA Host controller driver requires some correction of Phy Control OOB timing for the COMINIT/COMWAKE parameters to correctly interoperate with different kinds of disks. Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com --- drivers/ata/ahci_xgene.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c index 03b6b0f..1d48371 100644 --- a/drivers/ata/ahci_xgene.c +++ b/drivers/ata/ahci_xgene.c @@ -163,11 +163,11 @@ static void xgene_ahci_set_phy_cfg(struct xgene_ahci_context *ctx, int channel) /* Disable fix rate */ writel(0x0001fffe, mmio + PORTPHY1CFG); readl(mmio + PORTPHY1CFG); /* Force a barrier */ - writel(0x5018461c, mmio + PORTPHY2CFG); + writel(0x28183219, mmio + PORTPHY2CFG); readl(mmio + PORTPHY2CFG); /* Force a barrier */ - writel(0x1c081907, mmio + PORTPHY3CFG); + writel(0x13081008, mmio + PORTPHY3CFG); readl(mmio + PORTPHY3CFG); /* Force a barrier */ - writel(0x1c080815, mmio + PORTPHY4CFG); + writel(0x00480815, mmio + PORTPHY4CFG); readl(mmio + PORTPHY4CFG); /* Force a barrier */ /* Set window negotiation */ val = readl(mmio + PORTPHY5CFG); -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] arm64: Remove the clock and PHY reference from the APM X-Gene SoC AHCI SATA Host controller dts node.
This patch removes all clocks and PHY references from the APM X-Gene
SoC AHCI SATA host controller and PHY DTS nodes. The clock and PHY
are no longer needed as they are handled by the firmware. By removing
only the reference is not enough as any un-used clock entry will get
disabled by the clock framework.
Signed-off-by: Loc Ho l...@apm.com
Signed-off-by: Suman Tripathi stripa...@apm.com
---
arch/arm64/boot/dts/apm-storm.dtsi | 92 --
1 file changed, 92 deletions(-)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index f8c40a6..fa1a57f 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -177,86 +177,6 @@
clock-output-names = eth8clk;
};
- sataphy1clk: sataphy1clk@1f21c000 {
- compatible = apm,xgene-device-clock;
- #clock-cells = 1;
- clocks = socplldiv2 0;
- reg = 0x0 0x1f21c000 0x0 0x1000;
- reg-names = csr-reg;
- clock-output-names = sataphy1clk;
- status = disabled;
- csr-offset = 0x4;
- csr-mask = 0x00;
- enable-offset = 0x0;
- enable-mask = 0x06;
- };
-
- sataphy2clk: sataphy1clk@1f22c000 {
- compatible = apm,xgene-device-clock;
- #clock-cells = 1;
- clocks = socplldiv2 0;
- reg = 0x0 0x1f22c000 0x0 0x1000;
- reg-names = csr-reg;
- clock-output-names = sataphy2clk;
- status = ok;
- csr-offset = 0x4;
- csr-mask = 0x3a;
- enable-offset = 0x0;
- enable-mask = 0x06;
- };
-
- sataphy3clk: sataphy1clk@1f23c000 {
- compatible = apm,xgene-device-clock;
- #clock-cells = 1;
- clocks = socplldiv2 0;
- reg = 0x0 0x1f23c000 0x0 0x1000;
- reg-names = csr-reg;
- clock-output-names = sataphy3clk;
- status = ok;
- csr-offset = 0x4;
- csr-mask = 0x3a;
- enable-offset = 0x0;
- enable-mask = 0x06;
- };
-
- sata01clk: sata01clk@1f21c000 {
- compatible = apm,xgene-device-clock;
- #clock-cells = 1;
- clocks = socplldiv2 0;
- reg = 0x0 0x1f21c000 0x0 0x1000;
- reg-names = csr-reg;
- clock-output-names = sata01clk;
- csr-offset = 0x4;
- csr-mask = 0x05;
- enable-offset = 0x0;
- enable-mask = 0x39;
- };
-
- sata23clk: sata23clk@1f22c000 {
- compatible = apm,xgene-device-clock;
- #clock-cells = 1;
- clocks = socplldiv2 0;
- reg = 0x0 0x1f22c000 0x0 0x1000;
- reg-names = csr-reg;
- clock-output-names = sata23clk;
- csr-offset = 0x4;
- csr-mask = 0x05;
- enable-offset = 0x0;
- enable-mask = 0x39;
- };
-
- sata45clk: sata45clk@1f23c000 {
- compatible = apm,xgene-device-clock;
- #clock-cells = 1;
- clocks = socplldiv2 0;
- reg = 0x0 0x1f23c000 0x0 0x1000;
- reg-names = csr-reg;
- clock-output-names = sata45clk;
- csr-offset = 0x4;
- csr-mask = 0x05;
- enable-offset = 0x0;
- enable-mask = 0x39;
- };
};
serial0: serial@1c02 {
@@ -273,7 +193,6 @@
compatible = apm,xgene-phy;
Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled
Quoting Tushar Behera (2014-07-10 23:18:54) On 06/13/2014 02:39 AM, Mike Turquette wrote: Quoting Tushar Behera (2014-06-12 00:29:23) On Wed, Jun 11, 2014 at 10:20 PM, Mike Turquette mturque...@linaro.org wrote: Quoting Tushar Behera (2014-06-10 22:32:17) When the output clock of AUDSS mux is disabled, we are getting kernel oops while doing a clk_get() on other clocks provided by AUDSS. Though user manual doesn't specify this dependency, we came across this issue while disabling the parent of AUDSS mux clocks. Hi Tushar, Can you help me understand better what the actual problem is? What is the root cause of the kernel oops? Currently AUDSS mux has two parents, XXTI crystal and MAU_EPLL clock. As per observation, when the output of AUDSS mux is gated, we are not able to do any operation on the clocks provided by MAU block (mostly the clocks used by ADMA and audio blocks). I tried to get a datasheet for Exynos 54xx but could not find it. I even looked at the public 5250 data sheet, but it is completely missing Chapter 34, Audio Subsystem, which apparently contains Figure 34-3, Clock names and clock tree diagram of MAUDIO_BLK. So without any clue about your hardware (not for lack of trying) I would guess that somewhere in the parent hierarchy you have an interface clock which must be enabled in order for you to touch the registers pertaining to the downstream audio clocks. Yes, right. As per observation, we need to keep the output of AUDSS mux enabled to access the registers present in MAU block. The right way to handle this requires two steps: 1) model your interface clock in the Linux clock framework if you haven't already (I assume it is a gate clock, or the child of a gate clock) The interface clock is already part of the clock framework. Great! 2) the clk_ops callbacks for the affected audio clocks should wrap their operations (i.e. critical secion) with a clk_enable/clk_disable pair, where the clock being enables/disable is the interface clock mentioned above in #1 The CCF is reentrant, so you can do this by simply using the top-level clk.h API from within your clk_ops callbacks. Right now, the clocks are registered with clk_register_mux, clk_register_div and clk_register_gate calls which in turn set appropriate clk_ops callbacks. If I need to wrap the register access during these clk_ops callbacks with clk_enable/clk_disable of interface lock, I would have to reimplement the clk_ops callbacks in clk-exynos-audss driver. Is that the approach that you are suggesting? Is there another way? This is one of the reasons why I don't like the basic clock types being subclassed by clock drivers. It's a brittle design that tends to fall over as soon as the basic clock types don't do what you need. And don't even get me started on how ugly clk-composite.c is! ;-) One hack you can do is to subclass the clk_ops for each of the basic clock types you use and add .prepare and .unprepare callbacks to them which enable/disable the interface clock. Some examples of this are merged and it may be what your clock driver does already. However this may not be very optimal if your consumer driver simply calls clk_prepare_enable at probe-time and never turns the interface clock off again... I might be totally wrong about the cause of the hang, but that's my best guess based on everyone's bug reports. There are 5 gate clocks within MAU block. While disabling the unused clocks, if CLK_MAU_EPLL is disabled first, then we are getting this system hang. Right. Then your accesses to the clock control register need to be protected by a clk_enable/clk_disable critical section. Regards, Mike Regards, Mike You mention calling clk_get on child clocks of the AUDSS mux fails, but I cannot imagine why. How can the enable/disable state of a clock affect the ability to clk_get other clocks? I might have a little vogue while updating the commit message (mentioning about clk_get which surely is only a s/w operation), but there is definitely some issue with handling those clocks under given scenario. I am on leave till end of this week, so I will update you more with the logs on Monday. Thanks, -- Tushar ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Tushar Behera -- To unsubscribe from this list: send the line 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 v11 4/8] ata: libahci: allow to use multiple PHYs
Hi,
On Mon, Jul 28, 2014 at 01:27:24PM -0400, Tejun Heo wrote:
On Mon, Jul 28, 2014 at 12:29:56PM +0200, Hans de Goede wrote:
...
+ if (!enabled_ports) {
+ dev_warn(dev, No port enabled\n);
+ return ERR_PTR(-ENODEV);
This should be:
rc = -ENODEV;
goto err_out;
Sorry for not catching that sooner.
Other then that the entire series looks good and is:
Acked-by: Hans de Goede hdego...@redhat.com
Antoine, can you please post an updated version of this patch? No
need to repost the whole series. Also, how should the series be
routed?
Sure, I'm doing this right away. Regarding the series, Kishon already
took patches 1-2.
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: at91: spi: request all csgpio in spi probe
Hi Alexandre,
On Tue, 29 Jul 2014 00:38:59 +0200
Alexandre Belloni alexandre.bell...@free-electrons.com wrote:
+ if (ret 0) {
+ dev_err(pdev-dev,
+ failed to configure csgpio#%u (%d)\n,
+ i, ret);
+ goto out_free;
+ }
+ }
+
Mark: maybe it would make sense to do devm_gpio_request_one() in
of_spi_register_master(), after of_get_named_gpio.
Might be the cleanest way to solve this issue, but you'll have to modify
all the drivers that request cs_gpio in their setup method/callback.
While this solves the particular issue Jiří is seeing, this will not
solve the case where PA14 (CS0) is not used by the spi driver at all. It
will remained muxed as CS0 and toggle when the spi master needs to
access CS0 until another driver muxes it to something else. I still
believe we should explicitly ask pinctrl to mux them as gpios.
Do we really care about this case ?
After all, if a given pin needs a specific muxing during kernel boot
(i.e. a pin connected to a gpio-led that needs to stay in its previous
state or a pin connected to the reset line of a device that needs to
stay up and running during kernel boot) the bootloader/bootstrap should
have muxed this pin appropriately before booting the kernel.
What do you mean by we should explicitly ask pinctrl to mux them as
gpios ?
Do you mean configuring all the pins as GPIOs when the pin controller is
probed, or just adding a new pinctrl state configuring the pin as an
output GPIO and reference it in the pinctrl-0 property of the spi
controller.
If the former, you'll break devices that needs their pins to stay in
the state they were during the bootloader/boostrap phase.
The latter won't work if the pin you request as GPIO is later requested
by another device (which, if I'm correct, is exactly the case you're
trying to solve).
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/4] arm64: Remove the clock and PHY reference from the APM X-Gene SoC AHCI SATA Host controller dts node.
On Tuesday 29 July 2014 12:24:50 Suman Tripathi wrote: This patch removes all clocks and PHY references from the APM X-Gene SoC AHCI SATA host controller and PHY DTS nodes. The clock and PHY are no longer needed as they are handled by the firmware. By removing only the reference is not enough as any un-used clock entry will get disabled by the clock framework. Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com This will break booting on older firmware versions I guess, and it does not confirm to the binding that lists the phy and clock properties as required. It doesn't sound like a good idea to apply it. Arnd -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] devicetree/bindings: Add binding for micron n25q512a memory
On Mon, Jul 07, 2014 at 10:25:54PM +0100, Scott Wood wrote: On Thu, 2014-07-03 at 23:08 -0500, Jain Priyanka-B32167 wrote: -Original Message- From: Wood Scott-B07421 Sent: Friday, July 04, 2014 3:40 AM To: Jain Priyanka-B32167 Cc: devicetree@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux- s...@vger.kernel.org; linux-...@lists.infradead.org Subject: Re: [PATCH] devicetree/bindings: Add binding for micron n25q512a memory On Thu, 2014-07-03 at 15:42 +0530, Priyanka Jain wrote: -Micron n25q512a memory is supported by m25p80 driver. Add compatible field required to support n25q512a in m25p80.txt -Add micron to the vendor-prefixes.txt file Signed-off-by: Priyanka Jain priyanka.j...@freescale.com --- Documentation/devicetree/bindings/mtd/m25p80.txt |1 + .../devicetree/bindings/vendor-prefixes.txt|1 + 2 files changed, 2 insertions(+), 0 deletions(-) Why did you send this to the ppc list but not the spi or mtd lists? [Jain Priyanka-B32167] Sorry, I missed that I'm having a hard time following the flow of how these SPI devices get bound -- is the compatible involved at all? I don't see this string (with vendor prefix included) in the driver. I do see a table that contains what looks like device IDs. If the device can report its id, shouldn't we rely on that rather than device tree compatible? -Scott [Jain Priyanka-B32167] Spi driver has a check to device name corresponding to device-id and compare to what is passed in dts string. Please go into more detail. I don't see where the string micron,n25q512a appears in the current kernel. I do see n25q512a, but how does that compare successfully with the version of the string that has a vendor compatible? The spi code has a hack to not require an of_device_id_table: of_register_spi_devices calls of_modalias_node, which for a given foo,bar compatible string will set spi-modalias to bar, by cutting off everything up to and including the comma. Later, spi_match_id can match a device with an spi_device_id-name of bar. Thus micron,n25q512a can match one of the entries already in drivers/mtd/spi-nor/spi-nor.c. This is a real pain when searching around. Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] pwm: add this patch to support the new pwm of Rockchip SoCs
Hi Olof,
Sorry, I didn't understand all of what you mean.
Please allow me to paste the following code [1].
在 2014年07月29日 00:58, Olof Johansson 写道:
On Mon, Jul 28, 2014 at 4:19 AM, caesar caesar.w...@rock-chips.com wrote:
Doug,
在 2014年07月28日 12:01, Doug Anderson 写道:
Caesar,
On Sun, Jul 27, 2014 at 7:00 AM, caesar caesar.w...@rock-chips.com
wrote:
/*I think will be show the faill log:-
* rockchip-pwm ff9301a0.pwm: can't request region for resource [mem
0xff9301a0-0xff93019f]
*/
pc-base = devm_ioremap_resource(dev, regs);
Did you actually code this up and try it and get this error?
Yeah.
I hadn't
tried it but I researched other dts files and it looked as if there
was one example that was doing this. ...but perhaps it wasn't
actually doing the ioremap_resource on both ranges.
I'd imagine that this is _probably_ equivalent to what Thierry was
suggesting, so if it didn't work then maybe Thierry's won't work
either?
I don't have any other great suggestions other than doing two memory
ranges for lcdc:
lcdc@ff93 {
compatible = rockchip,rk3288-lcdc;
reg = 0xff93 0x1a0, 0xff9301b0 0xfe50;
...
};
pwm@ff9301a0 {
compatible = rockchip,vop-pwm;
reg = 0xff9301a0 0x10;
...
};
...but I am certainly nowhere near an expert on this stuff...
-Doug
I has solve in lcdc driver,but I always feel awkward. I think a good way to
solve in pwm driver.
Unfortunately that so far ,I have not a good idle in pwm driver.
Maybe,I let do it that way in lcdc driver.
I think there's an easier way to do this, by not focusing _too_ much
on the device tree:
* Define a platform_data structure for the PWM driver, which contains
readl/writel accessors as well as the device type (i.e. what you use
the compatible field and the lookup table for today).
Maybe, as the following code: pwm_data_vop has been implement it. right?
* Populate the platform_device in the clcd driver, and register that
Yeah,the lcdc driver can register it.
* Make the PWM driver probe as a regular platform device if pdata is passed
* Make a readl/writel wrapper that either falls back to native
readl/writel when there aren't any passed in, or make the DT code fill
in the pdata with the native versions in that case.
Sorry,This step I don't understand it. Perhaps, could you give a simple
case for it ?:-P
Going full MFD on this seems overkill, unless there is also a shared
interrupt that needs to be handled.
-Olof
[1]:The driver/pwm/pwm-rockchip.c
#include linux/clk.h
#include linux/io.h
#include linux/module.h
#include linux/of.h
#include linux/of_device.h
#include linux/platform_device.h
#include linux/pwm.h
#include linux/time.h
#define PWM_CNTR0x00/* Counter register */
#define PWM_HRC0x04/* High reference register */
#define PWM_LRC0x08/* Low reference register */
#define PWM_CTRL0x0c/* Control register */
#define PWM_CTRL_TIMER_EN(1 0)
#define PWM_CTRL_OUTPUT_EN(1 3)
#define PRESCALER2
#define PWM_ENABLE(1 0)
#define PWM_CONTINUOUS(1 1)
#define PWM_DUTY_POSITIVE(1 3)
#define PWM_INACTIVE_NEGATIVE(0 4)
#define PWM_OUTPUT_LEFT(0 5)
#define PWM_LP_DISABLE(0 8)
struct rockchip_pwm_chip {
struct pwm_chip chip;
struct clk *clk;
const struct rockchip_pwm_data *data;
void __iomem *base;
};
struct rockchip_pwm_regs {
unsigned long duty;
unsigned long period;
unsigned long cntr;
unsigned long ctrl;
};
struct rockchip_pwm_data {
struct rockchip_pwm_regs regs;
unsigned int prescaler;
void (*set_enable)(struct pwm_chip *chip, bool enable);
};
static inline struct rockchip_pwm_chip *to_rockchip_pwm_chip(struct
pwm_chip *c)
{
return container_of(c, struct rockchip_pwm_chip, chip);
}
static void rockchip_pwm_set_enable_v1(struct pwm_chip *chip, bool enable)
{
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
u32 val = 0;
u32 enable_conf = PWM_CTRL_OUTPUT_EN | PWM_CTRL_TIMER_EN;
val = readl_relaxed(pc-base + pc-data-regs.ctrl);
if (enable)
val |= enable_conf;
else
val = ~enable_conf;
writel_relaxed(val, pc-base + pc-data-regs.ctrl);
}
static void rockchip_pwm_set_enable_v2(struct pwm_chip *chip, bool enable)
{
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
u32 val = 0;
u32 enable_conf = PWM_OUTPUT_LEFT | PWM_LP_DISABLE | PWM_ENABLE |
PWM_CONTINUOUS | PWM_DUTY_POSITIVE | PWM_INACTIVE_NEGATIVE;
val = readl_relaxed(pc-base + pc-data-regs.ctrl);
if (enable)
val |= enable_conf;
else
val = ~enable_conf;
writel_relaxed(val, pc-base + pc-data-regs.ctrl);
}
static int rockchip_pwm_config(struct pwm_chip *chip, struct pwm_device
*pwm,
int duty_ns, int period_ns)
{
Re: [v2] input: drv260x: Add TI drv260x haptics driver
On Mon, Jul 28, 2014 at 05:53:23PM +0100, Dan Murphy wrote:
Add the TI drv260x haptics/vibrator driver.
This device uses the input force feedback
to produce a wave form to driver an
ERM or LRA actuator device.
The initial driver supports the devices
real time playback mode. But the device
has additional wave patterns in ROM.
This functionality will be added in
future patchsets.
Product data sheet is located here:
http://www.ti.com/product/drv2605
Signed-off-by: Dan Murphy dmur...@ti.com
---
v2 - Fixed binding doc and patch headline -
https://patchwork.kernel.org/patch/4619641/
.../devicetree/bindings/input/ti,drv260x.txt | 44 ++
drivers/input/misc/Kconfig |9 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/drv260x.c | 537
include/dt-bindings/input/ti-drv260x.h | 30 ++
include/linux/input/drv260x.h | 181 +++
6 files changed, 802 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt
create mode 100644 drivers/input/misc/drv260x.c
create mode 100644 include/dt-bindings/input/ti-drv260x.h
create mode 100644 include/linux/input/drv260x.h
diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt
b/Documentation/devicetree/bindings/input/ti,drv260x.txt
new file mode 100644
index 000..930429b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
@@ -0,0 +1,44 @@
+Texas Instruments - drv260x Haptics driver family
+
+The drv260x family serial control bus communicates through I2C protocols
+
+Required properties:
+ - compatible - One of:
+ ti,drv2604 - DRV2604
+ ti,drv2605 - DRV2605
+ ti,drv2605l - DRV2605L
+ - reg - I2C slave address
+ - mode - Power up mode of the chip (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_RTP_MODE - Real time playback mode
+ DRV260X_LRA_MODE - Linear Resonance Actuator mode
(Piezoelectric)
+ DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary
vibrator)
What exactly are these, and why does the kernel not decide?
+ - library_sel - Library to use at power up (defined in
include/dt-bindings/input/ti-drv260x.h)
Please s/_/-/ in all property names.
+ DRV260X_LIB_A - Pre-programmed Library
+ DRV260X_LIB_B - Pre-programmed Library
+ DRV260X_LIB_C - Pre-programmed Library
+ DRV260X_LIB_D - Pre-programmed Library
+ DRV260X_LIB_E - Pre-programmed Library
+ DRV260X_LIB_F - Pre-programmed Library
What exactly are these, and why does the kernel not decide?
+
+Optional properties:
+ - enable-gpio - gpio pin to enable/disable the device.
+ - vib_rated_voltage - The rated voltage of the actuator. If this is
not
+ set then the value will be
defaulted to 0x90 in the
+ driver.
What units is this in?
Don't mention the driver, just say if not 0x90 (but with a better
description of what 0x90 actually means).
+ - vib_overdrive_voltage - The overdrive voltage of the actuator.
+ If this is not set
then the value
+ will be defaulted to
0x90 in the driver.
Similarly on both points.
[...]
+static int drv260x_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct drv260x_data *haptics;
+ struct device_node *np = client-dev.of_node;
+ struct drv260x_platform_data *pdata = client-dev.platform_data;
+ struct ff_device *ff;
+ int ret;
+ int voltage;
+
+ haptics = devm_kzalloc(client-dev, sizeof(*haptics), GFP_KERNEL);
+ if (!haptics)
+ return -ENOMEM;
+
+ haptics-rated_voltage = DRV260X_DEF_OD_CLAMP_VOLT;
+ haptics-rated_voltage = DRV260X_DEF_RATED_VOLT;
+
+ if (np) {
+ ret = of_property_read_u32(np, mode, haptics-mode);
+ if (ret 0) {
+ dev_err(client-dev,
+ %s: No entry for mode\n, __func__);
+
+ return ret;
+ }
No sanity checking on the actual value?
As far as I can see, haptics-mode is an int, not a u32.
+ ret = of_property_read_u32(np, library_sel,
+ haptics-library);
+ if (ret 0) {
+ dev_err(client-dev,
+ %s: No entry for library selection\n,
__func__);
+
+ return ret;
+ }
Sanity checking?
haptics-library is not a u32.
Re: [PATCH v3 2/2] ASoC: fsl_asrc: Add ASRC ASoC CPU DAI and platform drivers
+ - big-endian : If this property is absent, the native endian mode will + be in use as default, or the big endian mode will be in use + for all the device registers. Native endian is meaningless. If a CPU supports both BE and LE, there is no native endianness. The endianness of the kernel is dynamic while the endianness of registers in HW is fixed. Just choose an endianness to assume by default (presumably little). That way this describes the HW and always works with a kernel of arbitrary endianness. Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/2] Add Freescale ASRC driver
This series of patches add Freescale ASRC module driver support along with the extra request in imx-sdma structure required by SDMA Device to Device script. The previous version has been in the maillist for nearly six months without any comment and reply. So I decide to drop the SDMA part's change since this series focus on ASRC support (Later, we can send SDMA part separately.) so that ASRC driver may get upstream first. Changelog v6: (Follows Mark Rutland's comments) * PATCH-2: Revised the big endian part in the binding document. v5: (All follow Varka's suggestions) * PATCH-2: Added missing '\n' to pair_err() calls. * PATCH-2: Return the final regmap_write() for fsl_asrc_init(). * PATCH-2: Dropped fsl_asrc_devtype and use simple ids behind fsl_asrc_pm. * PATCH-2: Use of_device_is_compatible() to differ compatible directly. * PATCH-2: Fixed indentation for devm_regmap_init_mmio_clk() call. v4: (All follow Varka's suggestions) * PATCH-2: Added '\n' to dev_dbg() inside fsl_asrc_isr(). * PATCH-2: Added indentations to DT binding document. * PATCH-2: Redefined fsl_asrc_set_watermarks() as void type. * PATCH-2: Put fsl_asrc_isr() and fsl_asrc_ids before probe() v3: * PATCH-1: Added an Acked-by from Shawn Guo * PATCH-2: Dropped THIS_MODULE as Tobias suggests * PATCH-2: Use dma_coerce_mask_and_coherent() in fsl_asrc_dma_pcm_new() * PATCH-2: Added substream check in fsl_asrc_dma_pcm_new() v2: * PATCH-1: Dropped the change to SDMA driver. * PATCH-2: Dropped useless member in private data structures. * PATCH-2: Refined some comments in fsl_asrc_dma.c driver. * PATCH-2: Refined commit comments. Nicolin Chen (2): ARM: imx: Add the secondary request into the structure for imx-sdma ASoC: fsl_asrc: Add ASRC ASoC CPU DAI and platform drivers .../devicetree/bindings/sound/fsl,asrc.txt | 60 ++ include/linux/platform_data/dma-imx.h | 1 + sound/soc/fsl/Kconfig | 9 + sound/soc/fsl/Makefile | 2 + sound/soc/fsl/fsl_asrc.c | 992 + sound/soc/fsl/fsl_asrc.h | 461 ++ sound/soc/fsl/fsl_asrc_dma.c | 386 7 files changed, 1911 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/fsl,asrc.txt create mode 100644 sound/soc/fsl/fsl_asrc.c create mode 100644 sound/soc/fsl/fsl_asrc.h create mode 100644 sound/soc/fsl/fsl_asrc_dma.c -- 1.8.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 v6 1/2] ARM: imx: Add the secondary request into the structure for imx-sdma
SDMA supports device to device (per_2_per) scripts to handle DMA transfering
between two peripheral devices. The per_2_per script, however, needs two dma
requests from two sides while the current structure only defined one request.
So this patch just simply adds the secondary request so as to let SDMA and
its user to add its implementation later.
[ Both change in the SDMA driver and its users like Freescale ASRC ASoC driver
should be taken along with this change in order to truly support per_2_per
sciprts. However, we here make an expediency by adding this first so that
we can add either side later since this patch won't break any function and
meanwhile it can make merge window more smoothly: we don't need to apply the
change inside dmaengine branch via ASoC tree any more. -- Nicolin ]
Signed-off-by: Nicolin Chen nicoleots...@gmail.com
Acked-by: Shawn Guo shawn@linaro.org
---
include/linux/platform_data/dma-imx.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/platform_data/dma-imx.h
b/include/linux/platform_data/dma-imx.h
index bcbc6c3..d05542a 100644
--- a/include/linux/platform_data/dma-imx.h
+++ b/include/linux/platform_data/dma-imx.h
@@ -50,6 +50,7 @@ enum imx_dma_prio {
struct imx_dma_data {
int dma_request; /* DMA request line */
+ int dma_request2; /* secondary DMA request line */
enum sdma_peripheral_type peripheral_type;
int priority;
};
--
1.8.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 v6 2/2] ASoC: fsl_asrc: Add ASRC ASoC CPU DAI and platform drivers
The Asynchronous Sample Rate Converter (ASRC) converts the sampling rate of a
signal associated with an input clock into a signal associated with a different
output clock. The driver currently works as a Front End of DPCM with other Back
Ends DAI links such as ESAI-CS42888 and SSI-WM8962 and SAI. It converts the
original sample rate to a common rate supported by Back Ends for playback while
converts the common rate of Back Ends to a desired rate for capture. It has 3
pairs to support three different substreams within totally 10 channels.
Signed-off-by: Nicolin Chen nicoleots...@gmail.com
Reviewed-by: Varka Bhadram varkabhad...@gmail.com
---
.../devicetree/bindings/sound/fsl,asrc.txt | 60 ++
sound/soc/fsl/Kconfig | 9 +
sound/soc/fsl/Makefile | 2 +
sound/soc/fsl/fsl_asrc.c | 992 +
sound/soc/fsl/fsl_asrc.h | 461 ++
sound/soc/fsl/fsl_asrc_dma.c | 386
6 files changed, 1910 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,asrc.txt
create mode 100644 sound/soc/fsl/fsl_asrc.c
create mode 100644 sound/soc/fsl/fsl_asrc.h
create mode 100644 sound/soc/fsl/fsl_asrc_dma.c
diff --git a/Documentation/devicetree/bindings/sound/fsl,asrc.txt
b/Documentation/devicetree/bindings/sound/fsl,asrc.txt
new file mode 100644
index 000..b93362a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,asrc.txt
@@ -0,0 +1,60 @@
+Freescale Asynchronous Sample Rate Converter (ASRC) Controller
+
+The Asynchronous Sample Rate Converter (ASRC) converts the sampling rate of a
+signal associated with an input clock into a signal associated with a different
+output clock. The driver currently works as a Front End of DPCM with other Back
+Ends Audio controller such as ESAI, SSI and SAI. It has three pairs to support
+three substreams within totally 10 channels.
+
+Required properties:
+
+ - compatible : Contains fsl,imx35-asrc or fsl,imx53-asrc.
+
+ - reg: Offset and length of the register set for the
device.
+
+ - interrupts : Contains the spdif interrupt.
+
+ - dmas : Generic dma devicetree binding as described in
+ Documentation/devicetree/bindings/dma/dma.txt.
+
+ - dma-names : Contains rxa, rxb, rxc, txa, txb and txc.
+
+ - clocks : Contains an entry for each entry in clock-names.
+
+ - clock-names: Contains the following entries
+ mem Peripheral access clock to access registers.
+ ipg Peripheral clock to driver module.
+ asrck_0-f Clock sources for input and output clock.
+
+ - big-endian: If this property is absent, the little endian
mode
+ will be in use as default. Otherwise, the big endian
+ mode will be in use for all the device registers.
+
+ - fsl,asrc-rate : Defines a mutual sample rate used by DPCM Back Ends.
+
+ - fsl,asrc-width: Defines a mutual sample width used by DPCM Back Ends.
+
+Example:
+
+asrc: asrc@02034000 {
+ compatible = fsl,imx53-asrc;
+ reg = 0x02034000 0x4000;
+ interrupts = 0 50 IRQ_TYPE_LEVEL_HIGH;
+ clocks = clks 107, clks 107, clks 0,
+ clks 0, clks 0, clks 0, clks 0,
+ clks 0, clks 0, clks 0, clks 0,
+ clks 0, clks 0, clks 0, clks 0,
+ clks 107, clks 0, clks 0;
+ clock-names = mem, ipg, asrck0,
+ asrck_1, asrck_2, asrck_3, asrck_4,
+ asrck_5, asrck_6, asrck_7, asrck_8,
+ asrck_9, asrck_a, asrck_b, asrck_c,
+ asrck_d, asrck_e, asrck_f;
+ dmas = sdma 17 23 1, sdma 18 23 1, sdma 19 23 1,
+sdma 20 23 1, sdma 21 23 1, sdma 22 23 1;
+ dma-names = rxa, rxb, rxc,
+ txa, txb, txc;
+ fsl,asrc-rate = 48000;
+ fsl,asrc-width = 16;
+ status = okay;
+};
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 52bbe9f..2fb8a43 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -2,6 +2,15 @@ menu SoC Audio for Freescale CPUs
comment Common SoC Audio options for Freescale CPUs:
+config SND_SOC_FSL_ASRC
+ tristate Asynchronous Sample Rate Converter (ASRC) module support
+ select REGMAP_MMIO
+ help
+ Say Y if you want to add Asynchronous Sample Rate Converter (ASRC)
+ support for the Freescale CPUs.
+ This option is only useful for out-of-tree drivers since
+ in-tree drivers select it automatically.
+
config SND_SOC_FSL_SAI
tristate Synchronous Audio Interface (SAI) module support
select REGMAP_MMIO
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index db254e3..9ff5926 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -11,6 +11,7 @@
Re: [PATCH v3 2/2] ASoC: fsl_asrc: Add ASRC ASoC CPU DAI and platform drivers
On Tue, Jul 29, 2014 at 10:46:13AM +0100, Mark Rutland wrote: + - big-endian : If this property is absent, the native endian mode will + be in use as default, or the big endian mode will be in use + for all the device registers. Native endian is meaningless. If a CPU supports both BE and LE, there is no native endianness. The endianness of the kernel is dynamic while the endianness of registers in HW is fixed. Just choose an endianness to assume by default (presumably little). That way this describes the HW and always works with a kernel of arbitrary endianness. Thank you for the comments. I just revised it by using 'little endian as default' and sent the patch v6. Please take a look at the new version. Thanks again, Nicolin -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] pwm: add this patch to support the new pwm of Rockchip SoCs
On Mon, Jul 28, 2014 at 07:19:18PM +0800, caesar wrote: Doug, 在 2014年07月28日 12:01, Doug Anderson 写道: Caesar, On Sun, Jul 27, 2014 at 7:00 AM, caesar caesar.w...@rock-chips.com wrote: /*I think will be show the faill log:- * rockchip-pwm ff9301a0.pwm: can't request region for resource [mem 0xff9301a0-0xff93019f] */ pc-base = devm_ioremap_resource(dev, regs); Did you actually code this up and try it and get this error? Yeah. This should work if you properly set up the PWM subregion as a child of the LCDC region, which is what MFD will do for you. Thierry pgpi7TvRdv8af.pgp Description: PGP signature
Re: [PATCH v2 2/2] pwm: add this patch to support the new pwm of Rockchip SoCs
On Mon, Jul 28, 2014 at 09:58:22AM -0700, Olof Johansson wrote:
On Mon, Jul 28, 2014 at 4:19 AM, caesar caesar.w...@rock-chips.com wrote:
Doug,
在 2014年07月28日 12:01, Doug Anderson 写道:
Caesar,
On Sun, Jul 27, 2014 at 7:00 AM, caesar caesar.w...@rock-chips.com
wrote:
/*I think will be show the faill log:-
* rockchip-pwm ff9301a0.pwm: can't request region for resource [mem
0xff9301a0-0xff93019f]
*/
pc-base = devm_ioremap_resource(dev, regs);
Did you actually code this up and try it and get this error?
Yeah.
I hadn't
tried it but I researched other dts files and it looked as if there
was one example that was doing this. ...but perhaps it wasn't
actually doing the ioremap_resource on both ranges.
I'd imagine that this is _probably_ equivalent to what Thierry was
suggesting, so if it didn't work then maybe Thierry's won't work
either?
I don't have any other great suggestions other than doing two memory
ranges for lcdc:
lcdc@ff93 {
compatible = rockchip,rk3288-lcdc;
reg = 0xff93 0x1a0, 0xff9301b0 0xfe50;
...
};
pwm@ff9301a0 {
compatible = rockchip,vop-pwm;
reg = 0xff9301a0 0x10;
...
};
...but I am certainly nowhere near an expert on this stuff...
-Doug
I has solve in lcdc driver,but I always feel awkward. I think a good way to
solve in pwm driver.
Unfortunately that so far ,I have not a good idle in pwm driver.
Maybe,I let do it that way in lcdc driver.
I think there's an easier way to do this, by not focusing _too_ much
on the device tree:
* Define a platform_data structure for the PWM driver, which contains
readl/writel accessors as well as the device type (i.e. what you use
the compatible field and the lookup table for today).
* Populate the platform_device in the clcd driver, and register that
* Make the PWM driver probe as a regular platform device if pdata is passed
* Make a readl/writel wrapper that either falls back to native
readl/writel when there aren't any passed in, or make the DT code fill
in the pdata with the native versions in that case.
That's one option, but it isn't going to work if you ever want to refer
to the PWM subdevice by phandle, since no phandle will exist.
Thierry
pgpf5ALpP53Je.pgp
Description: PGP signature
Re: [PATCH v2 2/2] pwm: add this patch to support the new pwm of Rockchip SoCs
On Sat, Jul 26, 2014 at 09:59:35PM -0700, Doug Anderson wrote:
caesar,
On Fri, Jul 25, 2014 at 3:29 AM, caesar caesar.w...@rock-chips.com wrote:
Hi Thierry,
在 2014年07月21日 21:27, Thierry Reding 写道:
On Mon, Jul 21, 2014 at 08:58:42PM +0800, caesar wrote:
于 2014年07月21日 16:50, Thierry Reding 写道:
On Sat, Jul 19, 2014 at 08:55:29PM +0800, Caesar Wang wrote:
[...]
struct rockchip_pwm_chip *pc;
struct resource *r;
int ret;
@@ -119,7 +182,10 @@ static int rockchip_pwm_probe(struct
platform_device *pdev)
return -ENOMEM;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- pc-base = devm_ioremap_resource(pdev-dev, r);
+ if (!strcmp(of_id-compatible, rockchip,vop-pwm))
+ pc-base = devm_ioremap(pdev-dev, r-start,
resource_size(r));
+ else
+ pc-base = devm_ioremap_resource(pdev-dev, r);
Sorry, this still isn't an option. You really shouldn't remap I/O
regions that other drivers may be using. You hinted at a shared register
space during the review of the initial version. Can you provide more
detail about what exactly the memory map looks like of the rk3288? Is
there some kind of technical reference manual that I could look at? Or
do you have a device tree extract that shows what the memory map looks
like?
Thierry
Maybe,you can look at the ARM: dts: rk3288:
https://github.com/rkchrome/kernel/blob/master/arch/arm/boot/dts/rk3288.dtsi
There is some lcdc and vop-pwm map address for rk3288.
,and you can look at the vop-introduce.pdf and vop-register.pdf in Annex.
Maybe,I should put the vop-pwm in lcdc driver,but I don't hope do so it.
Could you give a suggestion to solve it? Thanks.
It looks like you could turn the lcdc device into an MFD device so that
it can instantiate two devices, one for the display controller, the
other for the PWM. Or perhaps it would even work with only a single
child device.
The device tree would become something like this:
lcdc@ff93 {
compatible = rockchip,rk3288-lcdc;
...
pwm@ff9301a0 {
compatible = rockchip,vop-pwm;
...
};
};
And your driver would do something like:
static const struct resource pwm_resources[] = {
{
.start = 0x1a0,
.end = 0x1af,
.flags = IORESOURCE_MEM,
},
};
static const struct mfd_cell subdevices[] = {
{
.name = pwm,
.id = 1,
.of_compatible = rockchip,vop-pwm,
.num_resources = ARRAY_SIZE(pwm_resources),
.resources = pwm_resources,
},
};
static int lcdc_probe(struct platform_device *pdev)
{
struct resource *regs;
...
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
...
err = mfd_add_devices(pdev-dev, 0, subdevices,
ARRAY_SIZE(subdevices),
regs, NULL, NULL);
...
}
Thierry
Sorry,I might a little trouble for the changes.
The driver changes only for lcdc? If that is the case,I suddenly don't know
how to do it ?
Maybe,I didn't say it clearly.
lcdc0: lcdc@ff93 | vop0pwm: pwm@ff9301a0
reg = 0xff93 0x1 | reg = 0xff9301a0 0x10;
The lcdc has to add resource's address from 0xff93 to 0xff93.
When the pwm driver is loading vop0pwm. the devm_ioremap_resource() will
be used in probe();
I think it will be occur a fail. because the resource [mem
0xff9301a0-0xff9301af] has be requested by lcdc.
=rockchip-pwm ff9301a0.pwm: can't request region for resource [mem
0xff9301a0-0xff9301af]
If I do the changes in pwm driver,do you have a other suggestion for it?
thanks.:-)
Sorry if this is stupid (and I haven't tried it), but does ranges
help solve this problem? AKA:
lcdc@ff93 {
compatible = rockchip,rk3288-lcdc;
reg = 0xff93 0x1;
#address-cells = 2;
#size-cells = 1;
ranges = 0 0xff9301a0 0x10;
...
pwm@0,0 {
compatible = rockchip,vop-pwm;
reg = 0 0 0x10;
...
};
};
Does that avoid the failure? The lcdc driver would need to call
of_platform_populate() to make the PWM show up.
If you add simple-bus to the lcdc compatible string, like so:
lcdc@ff93 {
Re: [PATCH v9] video: ARM CLCD: Add DT support
On Tue, 2014-07-22 at 11:02 +0100, Pawel Moll wrote: On Tue, 2014-07-08 at 14:06 +0100, Pawel Moll wrote: On Tue, 2014-06-24 at 12:55 +0100, Pawel Moll wrote: This patch adds basic DT bindings for the PL11x CLCD cells and make their fbdev driver use them. Signed-off-by: Pawel Moll pawel.m...@arm.com As two weeks passed without any further comment, I'm assuming that there are no more obstacles for this patch to be merged. Tomi, will you pick it up for 3.17, as you offered? Russell, if you prefer to take it via your tree, it's in your system as 8005/4. Ping... Tomi? ... and again... Regards Pawel -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] pwm: add this patch to support the new pwm of Rockchip SoCs
Thierry, 在 2014年07月29日 18:22, Thierry Reding 写道: On Mon, Jul 28, 2014 at 07:19:18PM +0800, caesar wrote: Doug, 在 2014年07月28日 12:01, Doug Anderson 写道: Caesar, On Sun, Jul 27, 2014 at 7:00 AM, caesar caesar.w...@rock-chips.com wrote: /*I think will be show the faill log:- * rockchip-pwm ff9301a0.pwm: can't request region for resource [mem 0xff9301a0-0xff93019f] */ pc-base = devm_ioremap_resource(dev, regs); Did you actually code this up and try it and get this error? Yeah. This should work if you properly set up the PWM subregion as a child of the LCDC region, which is what MFD will do for you. Thierry As you say,should this change be occured by lcdc driver and dts? The PWM driver don't need do any changes? -- To unsubscribe from this list: send the line 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 v9] video: ARM CLCD: Add DT support
Hi, On 29/07/14 14:06, Pawel Moll wrote: On Tue, 2014-07-22 at 11:02 +0100, Pawel Moll wrote: On Tue, 2014-07-08 at 14:06 +0100, Pawel Moll wrote: On Tue, 2014-06-24 at 12:55 +0100, Pawel Moll wrote: This patch adds basic DT bindings for the PL11x CLCD cells and make their fbdev driver use them. Signed-off-by: Pawel Moll pawel.m...@arm.com As two weeks passed without any further comment, I'm assuming that there are no more obstacles for this patch to be merged. Tomi, will you pick it up for 3.17, as you offered? Russell, if you prefer to take it via your tree, it's in your system as 8005/4. Ping... Tomi? Yep, I've queued it now for 3.17. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT based off
kgene's for-next branch due to DT, and I run into the following:
CC drivers/gpu/drm/bridge/ptn3460.o
drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’:
drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
drm_connector_register(ptn_bridge-connector);
^
Hope this might help:
http://www.spinics.net/lists/dri-devel/msg60578.html
That fixed my build, thanks.
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
For testing I re-applied your iommu patches (which btw fail now for 5420
due to disp_pd) but didn't know what to do about your panel-lvds
regulator patch now that it's gone.
If I don't apply this series, then commenting out the dp-controller node
gets me a working display with simplefb as before.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas Färber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+ panel: panel {
+ compatible = simple-panel;
+ };
+
dp-controller@145B {
status = okay;
pinctrl-names = default;
- pinctrl-0 = dp_hpd;
+ pinctrl-0 = dp_hpd_gpio;
samsung,color-space = 0;
samsung,dynamic-range = 0;
samsung,ycbcr-coeff = 0;
@@ -75,6 +79,7 @@
samsung,link-rate = 0x0a;
samsung,lane-count = 1;
samsung,hpd-gpio = gpc3 0 0;
+ bridge = ps8622;
};
fixed-rate-clocks {
@@ -387,6 +392,17 @@
status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
+
+ ps8622: ps8622-bridge@08 {
+ compatible = parade,ps8622;
+ reg = 0x08;
+ sleep-gpios = gpc3 6 0;
+ reset-gpios = gpc3 1 0;
+ lane-count = 1;
+ panel = panel;
+ pinctrl-names = default;
+ pinctrl-0 = ps8622_gpios;
+ };
};
i2c_8 {
@@ -450,6 +466,20 @@
samsung,pin-pud = 0;
};
+ dp_hpd_gpio: dp-hpd-gpio {
+ samsung,pins = gpc3-0;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 0;
+ };
+
+ ps8622_gpios: ps8622-gpios {
+ samsung,pins = gpc3-1, gpc3-6;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
s5m8767_dvs: s5m8767-dvs {
samsung,pins = gpd1-0, gpd1-1, gpd1-2;
samsung,pin-function = 0;
--
1.9.3
Re: [PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
Am 25.07.2014 21:22, schrieb Ajay Kumar:
From: Vincent Palatin vpala...@chromium.org
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/vendor-prefixes.txt|1 +
.../devicetree/bindings/video/bridge/ps8622.txt| 19 +
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile|1 +
drivers/gpu/drm/bridge/ps8622.c| 602
5 files changed, 633 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 46a311e..b4a99cc 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -96,6 +96,7 @@ nxp NXP Semiconductors
onnn ON Semiconductor Corp.
opencoresOpenCores.org
panasonicPanasonic Corporation
+parade Parade Technologies Inc.
phytec PHYTEC Messtechnik GmbH
picochip Picochip Ltd
plathome Plat'Home Co., Ltd.
diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..fdeafb2
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,19 @@
+ps8622-bridge bindings
+
+Required properties:
+ - compatible: parade,ps8622 or parade,ps8625
+ - reg: first i2c address of the bridge
+ - sleep-gpios: OF device-tree gpio specification
+ - reset-gpios: OF device-tree gpio specification
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+
+Example:
+ ps8622-bridge@48 {
Nit: Shouldn't this be lvds-bridge like in 7/8 or something else not
derived from the specific model? Applies to the DT series as well.
+ compatible = parade,ps8622;
+ reg = 0x48;
+ sleep-gpios = gpc3 6 1 0 0;
+ reset-gpios = gpc3 1 1 0 0;
+ lane-count = 1
+ };
[...]
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..ec60fcf
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,602 @@
+/*
+ * Parade PS8622 eDP/LVDS bridge driver
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
[...]
+MODULE_AUTHOR(Vincent Palatin vpala...@chromium.org);
+MODULE_DESCRIPTION(Parade ps8622 eDP-LVDS converter driver);
+MODULE_LICENSE(GPL);
GPL v2?
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: at91: spi: request all csgpio in spi probe
On Tue, Jul 29, 2014 at 12:38:59AM +0200, Alexandre Belloni wrote: Mark: maybe it would make sense to do devm_gpio_request_one() in of_spi_register_master(), after of_get_named_gpio. You need to transition all the drivers doing things manually but yes. As I keep saying all the GPIO handling needs to be completely refactored. While this solves the particular issue Jiří is seeing, this will not solve the case where PA14 (CS0) is not used by the spi driver at all. It will remained muxed as CS0 and toggle when the spi master needs to access CS0 until another driver muxes it to something else. I still believe we should explicitly ask pinctrl to mux them as gpios. I'm just guessing as to what the issue that he's seeing is but isn't this just saying that the board pinmuxing is wrong? If the board doesn't want the pin to be used by the SPI controller it shouldn't be configuring it that way. signature.asc Description: Digital signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT based off
kgene's for-next branch due to DT, and I run into the following:
CC drivers/gpu/drm/bridge/ptn3460.o
drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’:
drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
drm_connector_register(ptn_bridge-connector);
^
Hope this might help:
http://www.spinics.net/lists/dri-devel/msg60578.html
That fixed my build, thanks.
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
For testing I re-applied your iommu patches (which btw fail now for 5420
due to disp_pd) but didn't know what to do about your panel-lvds
regulator patch now that it's gone.
If I don't apply this series, then commenting out the dp-controller node
gets me a working display with simplefb as before.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+ panel: panel {
+ compatible = simple-panel;
+ };
You can't do this. simple-panel isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Thierry
pgpL60lTIwZPr.pgp
Description: PGP signature
Re: [PATCH v2 2/2] pwm: add this patch to support the new pwm of Rockchip SoCs
On Tue, Jul 29, 2014 at 07:09:07PM +0800, caesar wrote: Thierry, 在 2014年07月29日 18:22, Thierry Reding 写道: On Mon, Jul 28, 2014 at 07:19:18PM +0800, caesar wrote: Doug, 在 2014年07月28日 12:01, Doug Anderson 写道: Caesar, On Sun, Jul 27, 2014 at 7:00 AM, caesar caesar.w...@rock-chips.com wrote: /*I think will be show the faill log:- * rockchip-pwm ff9301a0.pwm: can't request region for resource [mem 0xff9301a0-0xff93019f] */ pc-base = devm_ioremap_resource(dev, regs); Did you actually code this up and try it and get this error? Yeah. This should work if you properly set up the PWM subregion as a child of the LCDC region, which is what MFD will do for you. Thierry As you say,should this change be occured by lcdc driver and dts? The PWM driver don't need do any changes? No, I don't think the PWM driver needs to be changed for the above to work. Thierry pgpqahRp8ZidJ.pgp Description: PGP signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Am 29.07.2014 13:36, schrieb Thierry Reding:
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT
[...]
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
[...]
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32
+++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+panel: panel {
+compatible = simple-panel;
+};
You can't do this. simple-panel isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Okay, that means the Snow DT is wrong, too:
https://patchwork.kernel.org/patch/4625441/
And the others specify it as fallback:
https://patchwork.kernel.org/patch/4625461/
https://patchwork.kernel.org/patch/4625451/
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
signature.asc
Description: OpenPGP digital signature
use IORESOURCE_REG resource type for non-translatable addresses in DT
Hi,
While looking in MFD drivers I saw that few of them (88pm860x-core,
max8925-core and wm831x-core) allow use of IORESOURCE_REG as resource
type when calling platform_get_resource() by their child drivers. The
resources for these child devices are filled by core MFD driver manually
and then passed to mfd_add_devices() as mfd_cells.
During development and review comments of the MFD core driver for
Qualcomm SPMI PMICs we came down to a need to describe PMIC peripheral
addresses (the PMIC sub-functions) through *reg* property in DT. The
PMIC peripheral drivers will be scattered over the /drivers and they
will call platform_get_resource() to extract their peripheral base
addresses from resource-start. The issue we have encountered is that
these addresses are non-translatable thus of_address_to_resource returns
OF_BAD_ADDR.
Stephen Boyd have made a suggestion to solve the issue here [1].
Is that approach acceptable? Or do we have better way? How similar
issues could be solved.
Our DT node for SPMI PMICs can be seen below [2].
Please do comment.
PS: I have made a little change in __of_address_to_resource() to
illustrate what I meant above.
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5edfcb0..898741e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -617,9 +617,24 @@ static int __of_address_to_resource(struct
device_node *dev,
if ((flags (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
return -EINVAL;
+
taddr = of_translate_address(dev, addrp);
- if (taddr == OF_BAD_ADDR)
- return -EINVAL;
+ /*
+* if the address is non-translatable to cpu physical address
+* fallback to a IORESOURCE_REG resource.
+*/
+ if (taddr == OF_BAD_ADDR) {
+ memset(r, 0, sizeof(*r));
+ taddr = of_read_number(addrp, 1);
+ if (taddr == OF_BAD_ADDR)
+ return -EINVAL;
+ r-start = taddr;
+ r-end = taddr + size - 1;
+ r-flags = IORESOURCE_REG;
+ r-name = name ? name : dev-full_name;
+ return 0;
+ }
+
memset(r, 0, sizeof(struct resource));
if (flags IORESOURCE_IO) {
unsigned long port;
[1] https://lkml.org/lkml/2014/7/17/680
[2] Simplistic PMIC DT node.
spmi@fc4cf000 {
compatible = qcom,spmi-pmic-arb;
reg = 0xfc4cf000 0x1000,
0xfc4cb000 0x1000,
0xfc4ca000 0x1000;
reg-names = core, intr, cnfg;
#address-cells = 2;
#size-cells = 0;
interrupt-controller;
#interrupt-cells = 4;
pm8941@0 {
compatible = qcom,pm8941;
reg = 0x0 SPMI_USID;
#size-cells = 1;
#address-cells = 1;
rtc {
compatible = qcom,pm8941-rtc;
reg = 0x6000 0x100, 0x6100 0x100;
reg-names = rtc, alarm;
interrupts = 0x0 0x61 0x1 0;
interrupt-names = alarm;
};
};
pm8941@1 {
compatible = qcom,pm8941;
reg = 0x1 SPMI_USID;
};
}
--
regards,
Stan
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Tue, Jul 29, 2014 at 01:36:46PM +0200, Thierry Reding wrote:
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT based off
kgene's for-next branch due to DT, and I run into the following:
CC drivers/gpu/drm/bridge/ptn3460.o
drivers/gpu/drm/bridge/ptn3460.c: In function
‘ptn3460_post_encoder_init’:
drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
drm_connector_register(ptn_bridge-connector);
^
Hope this might help:
http://www.spinics.net/lists/dri-devel/msg60578.html
That fixed my build, thanks.
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
For testing I re-applied your iommu patches (which btw fail now for 5420
due to disp_pd) but didn't know what to do about your panel-lvds
regulator patch now that it's gone.
If I don't apply this series, then commenting out the dp-controller node
gets me a working display with simplefb as before.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32
+++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+ panel: panel {
+ compatible = simple-panel;
+ };
You can't do this. simple-panel isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Done.
Thierry
pgpmqQCKKbm5A.pgp
Description: PGP signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
Am 29.07.2014 13:36, schrieb Thierry Reding:
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT
[...]
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
[...]
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32
+++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+ panel: panel {
+ compatible = simple-panel;
+ };
You can't do this. simple-panel isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Okay, that means the Snow DT is wrong, too:
https://patchwork.kernel.org/patch/4625441/
And the others specify it as fallback:
https://patchwork.kernel.org/patch/4625461/
https://patchwork.kernel.org/patch/4625451/
A quick grep shows that many (all?) devices that use DRM panels provide
simple-panel as fallback. That's probably fine as long as they also do
provide the specific model. But given that simple-panel does not have a
mode or physical size, I don't think even that makes sense.
Any of the DTS files in the tree I have that list simple-panel as a
fallback are Tegra, so I'll go write a patch that removes the fallback.
I can't think of a reason why it would ever be needed or meaningful.
Thierry
pgpB_WPHduT__.pgp
Description: PGP signature
Re: use IORESOURCE_REG resource type for non-translatable addresses in DT
On Tuesday 29 July 2014 14:42:31 Stanimir Varbanov wrote:
taddr = of_translate_address(dev, addrp);
- if (taddr == OF_BAD_ADDR)
- return -EINVAL;
+ /*
+* if the address is non-translatable to cpu physical address
+* fallback to a IORESOURCE_REG resource.
+*/
+ if (taddr == OF_BAD_ADDR) {
+ memset(r, 0, sizeof(*r));
+ taddr = of_read_number(addrp, 1);
+ if (taddr == OF_BAD_ADDR)
+ return -EINVAL;
+ r-start = taddr;
+ r-end = taddr + size - 1;
+ r-flags = IORESOURCE_REG;
+ r-name = name ? name : dev-full_name;
+ return 0;
+ }
+
I don't think that everything returning OF_BAD_ADDR makes sense
to turn into IORESOURCE_REG. It could be an e.g. invalid DT
representation, a node with #size-cells=0, or it could be
something that gets translated one or more nodes up in the
tree before it reaches a bus without a ranges property.
Also, you should not rely on #address-cells being hardcoded
to 1 above.
How about modifying of_get_address() rather than
__of_address_to_resource() instead? You could introduce
a new of_bus entry for each bus you expect to return
an IORESOURCE_REG, or you could change of_bus_default_get_flags
to return IORESOURCE_REG if the parent node has no ranges property
and is not the root node.
Arnd
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 30/35] irqchip: add irq-omap-intc.h header
* Felipe Balbi ba...@ti.com [140728 14:19]: OMAP INTC irqchip driver will be moved under drivers/irqchip/ soon but we still have a dependency with mach-omap2 when it comes to idle functions. In order to make it easy to share those function prototypes with OMAP PM code, we introduce this new header. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap2/board-3430sdp.c| 1 + arch/arm/mach-omap2/board-am3517crane.c| 1 + arch/arm/mach-omap2/board-am3517evm.c | 1 + arch/arm/mach-omap2/board-cm-t35.c | 1 + arch/arm/mach-omap2/board-cm-t3517.c | 1 + arch/arm/mach-omap2/board-devkit8000.c | 1 + arch/arm/mach-omap2/board-ldp.c| 1 + arch/arm/mach-omap2/board-omap3beagle.c| 1 + arch/arm/mach-omap2/board-omap3logic.c | 1 + arch/arm/mach-omap2/board-omap3pandora.c | 1 + arch/arm/mach-omap2/board-omap3stalker.c | 1 + arch/arm/mach-omap2/board-omap3touchbook.c | 1 + arch/arm/mach-omap2/board-overo.c | 1 + arch/arm/mach-omap2/board-rx51.c | 1 + arch/arm/mach-omap2/board-ti8168evm.c | 1 + arch/arm/mach-omap2/common.h | 9 - arch/arm/mach-omap2/cpuidle34xx.c | 1 + arch/arm/mach-omap2/irq.c | 1 + arch/arm/mach-omap2/pm24xx.c | 1 + arch/arm/mach-omap2/pm34xx.c | 1 + include/linux/irqchip/irq-omap-intc.h | 32 ++ ... +void omap2_init_irq(void); +void omap3_init_irq(void); +void ti81xx_init_irq(void); I think these will all go away with DT based booting? So it might be worth waiting for that rather than churn all these files, or.. +int omap_irq_pending(void); +void omap_intc_save_context(void); +void omap_intc_restore_context(void); +void omap3_intc_suspend(void); +void omap3_intc_prepare_idle(void); +void omap3_intc_resume_idle(void); ..how about we pass something like struct omap_intc_data as pdata and let the intc driver populate function pointers for these if runtime PM calls are not enough here? That way we could have just minimal pdata header file. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain
* Felipe Balbi ba...@ti.com [140728 14:19]: now that we don't need to support legacy board-files, we can completely switch over to a linear irq domain and make use of irq_alloc_domain_generic_chips() to allocate all generic irq chips for us. This patch seems to somehow break off-idle for omap3 where it no longer wakes up. Other than that, this whole series boots fine for me. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2] input: drv260x: Add TI drv260x haptics driver
On Monday 28 of July 2014 21:21:26 Murphy, Dan wrote: Dmitry On 07/28/2014 12:59 PM, si...@mungewell.org wrote: The initial driver supports the devices real time playback mode. But the device has additional wave patterns in ROM. As it presented the device appears to be a memoryless device, however you present it to the rest of the system as if it can support playback of multiple effects simultaneously, which is incorrect. My guess that you need to engage the memoryless input library to schedule handling multiple effects for your device, including ramping up, ramping down, stopping playback when effects runs out, etc. Hi Dan, Elias and Michal (cc'ed) are working on a kernel/userland library to handle sending multiple force feedback signals to 'simple' devices, perhaps you should engage with them. Simon Hi Dan, since I spent some time trying to improve the memoryless library I can hopefully provide you with some hints. If I'm reading this right, your device cannot play more than one effect at once but it can operate eihter in RTP mode where the user controls the operation of the motors directly on in an automated mode where the device follows some pre- programmed waveform. These two modes are mutually exclusive. If my understanding of the problem is correct, you will struggle both with memoryless library and your own imlementation. The memoryless library is quite simplistic and it doesn't have any sort of passthrough mode so you would not be able to do anything besides RTP that way. On the other hand if you decide to write your own implementation of effect handling you will end up duplicating a lot of code that already exists in the memoryless library and has been proven to work. A possible solution for the problem would be to separate the functions that control effect timing from the memoryless library and make them globally accessible. I believe that this would simplify any customized haptic implementation considerably and it might be a decent interim solution before the project Simon mentioned is ready. If there is anybody interested in such a solution I can probably whip up a patch for it quite quickly. Regards, 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 3/3] arm: dts: Add gta04a5 model
* Dr. H. Nikolaus Schaller h...@goldelico.com [140728 13:45]: Yes, the boot loader either loads gta04a3.dtb gta04.dtb or gta05.dtb depending on board revision. Therefore we have multiple device tree files to represent such hardware differences. Like Gumstix Overo variants (using a omap3-overo-base.dtsi) And, this difference is not the only one. Other are to come later. Unfortunately we were recommend to submit only DT nodes that already have drivers. Therefore, the big picture of the device variants support may not yet be visible from this patch. I hope this gives a little background. So what's the conclusion? Are changes needed to this patch series or not? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: dts: exynos5250: Fold common ChromeOS parts into Snow
Doug,
Am 25.07.2014 18:02, schrieb Doug Anderson:
On Fri, Jul 18, 2014 at 10:20 AM, Andreas Färber afaer...@suse.de wrote:
+/*
+ * On Snow we've got SIP WiFi and so can keep drive strengths low to
+ * reduce EMI.
+ */
+mmc_3 {
+ status = okay;
+ num-slots = 1;
+ supports-highspeed;
+ broken-cd;
+ card-detect-delay = 200;
+ samsung,dw-mshc-ciu-div = 3;
+ samsung,dw-mshc-sdr-timing = 2 3;
+ samsung,dw-mshc-ddr-timing = 1 2;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 4;
+ pinctrl-names = default;
+ pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
This actually looks like a bug on snow. I don't think these pinctrl
statements are taking effect and I think they belong at the mmc level,
not the slot level. That's not a new bug introduced by you, though.
Mind fixing it? You've already got it right for Spring mmc_1.
I was taught never to mix code movements with functional changes, as it
hides them even if mentioned in the commit message. Would you like me to
fix it pre- or post-move? Post-move would be easiest for me. ;)
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line 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/4] ARM: dts: exynos5250: Fold common ChromeOS parts into Snow
Hi Javier and Doug,
Am 25.07.2014 19:02, schrieb Javier Martinez Canillas:
On Fri, Jul 25, 2014 at 6:43 PM, Doug Anderson diand...@chromium.org wrote:
On Fri, Jul 25, 2014 at 9:35 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
Hello Andreas,
On Fri, Jul 18, 2014 at 7:20 PM, Andreas Färber afaer...@suse.de wrote:
+ memory {
+ reg = 0x4000 0x8000;
+ };
+
+ chosen {
+ };
+
Is there a reason for an empty chosen node? Same for the Spring DTS.
I know that the bootloader (U-Boot) fills this in. I'd have to double
check how the bootloader handles the node not being there to begin
with.
Yes, U-Boot fills this but if the node does not exist in the FDT, it
creates one. Take a look at fdt_chosen() in common/fdt_support.c [0].
So I think it's better to just remove it since is empty.
Hm, in different context it was stated that device trees shouldn't rely
on bootloader behavior (for a /memory node on Zynq we ended up
specifying the size cell with the real value despite U-Boot overriding
it to a lesser value).
Can we instead settle on filling this node with defaults? :)
bootargs = console=tty1; would be my choice for Spring. Would that be
applicable for Snow as well?
Not sure how to specify that via linux,stdout-path property.
I believe this would be a follow-up patch either way.
Since there's at least two series out there trying to fiddle with
-cros-common.dtsi, including one that drops the slot sub-node of the MMC
and one that adds CPU power supply, it would be nice if we can get the
-cros-common parts sorted out and applied. Can you ack/review 1-2?
Should I squash them in a v3?
Thanks,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line 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] arm: dts: Add gta04a5 model
Hi, Am 29.07.2014 um 14:41 schrieb Tony Lindgren: * Dr. H. Nikolaus Schaller h...@goldelico.com [140728 13:45]: Yes, the boot loader either loads gta04a3.dtb gta04.dtb or gta05.dtb depending on board revision. Therefore we have multiple device tree files to represent such hardware differences. Like Gumstix Overo variants (using a omap3-overo-base.dtsi) And, this difference is not the only one. Other are to come later. Unfortunately we were recommend to submit only DT nodes that already have drivers. Therefore, the big picture of the device variants support may not yet be visible from this patch. I hope this gives a little background. So what's the conclusion? Are changes needed to this patch series or not? I advocate that no changes are needed. BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 10/14] drm/panel: add S6E3FA0 driver
Hi Thierry,
Sorry for late reply.
I implemented common DSI helper functions and tested in s6e3fa0 panel
(I should test with other panels).
The helper function prototypes are like below:
int mipi_dsi_set_maximum_return_packet_size(struct mipi_dsi_device *dsi,
u16 size);
int mipi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi);
int mipi_dcs_exit_sleep_mode(struct mipi_dsi_device *dsi);
int mipi_dcs_set_display_off(struct mipi_dsi_device *dsi);
int mipi_dcs_set_display_on(struct mipi_dsi_device *dsi);
int mipi_dcs_set_tear_off(struct mipi_dsi_device *dsi);
enum mipi_dcs_tear_mode {
MIPI_DCS_TEAR_MODE_VBLANK,
MIPI_DCS_TEAR_MODE_HVBLANK,
};
int mipi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
enum mipi_dcs_tear_mode mode);
Last time you recommended to implement mipi_dcs_set_tear_on() unrelated
with mipi_dsi_dcs_write().
As you know, the only difference between mipi_dcs_xxx() except
mipi_dcs_set_tear_on() is data(dcs command).
So I think it's better to use mipi_dsi_dcs_write() instead.
Do you agree?
And one more thing.
From my point of view there is no initialization sequence in simple
panel driver, so this and s6e8aa0 panel couldn't use that interface.
The s6e3fa0 and s6e8aa0 are very similar so I think it is possible to
combine together like simple panel driver.
I want to ask you for advice on this.
Thank you.
Best regards YJ
On 07/22/2014 12:56 PM, YoungJun Cho wrote:
Hi Thierry,
Now I understand what you mean.
I'll implement common DSI helper functions.
Thank you.
Best regards YJ
On 07/21/2014 06:35 PM, Thierry Reding wrote:
On Fri, Jul 18, 2014 at 10:49:35AM +0900, YoungJun Cho wrote:
Hi Thierry,
Thank you a lot for kind comments.
On 07/17/2014 07:36 PM, Thierry Reding wrote:
On Thu, Jul 17, 2014 at 06:01:25PM +0900, YoungJun Cho wrote:
[...]
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
[...]
+static void s6e3fa0_set_maximum_return_packet_size(struct s6e3fa0
*ctx,
+unsigned int size)
+{
+struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx-dev);
+const struct mipi_dsi_host_ops *ops = dsi-host-ops;
+
+if (ops ops-transfer) {
+unsigned char buf[] = {size, 0};
+struct mipi_dsi_msg msg = {
+.channel = dsi-channel,
+.type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE,
+.tx_len = sizeof(buf),
+.tx_buf = buf
+};
+
+ops-transfer(dsi-host, msg);
+}
+}
The Set Maximum Return Packet Size command is a standard command, so
please turn that into a generic function exposed by the DSI core.
For this and below standard DCS commands, you want to use generic
functions,
but I have no idea for that.
Could you explain more detail?
The goal should be to make these standard DCS commands available to all
DSI peripherals, so the implementation should look something like this:
static int mipi_dsi_set_maximum_return_packet_size(struct
mipi_dsi_device *dsi,
u16 size)
{
struct mipi_dsi_msg msg;
if (!dsi-ops || !dsi-ops-transfer)
return -ENOSYS;
memset(msg, 0, sizeof(msg));
msg.channel = dsi-channel;
msg.type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE;
msg.tx_len = sizeof(size);
msg.tx_buf = size;
return dsi-ops-transfer(dsi-host, msg);
}
The above is somewhat special, since it isn't DCS. For DCS I'd suggest a
common prefix, like so:
enum mipi_dcs_tear_mode {
MIPI_DCS_TEAR_VBLANK,
MIPI_DCS_TEAR_BLANK,
};
static int mipi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
enum mipi_dcs_tear_mode mode)
{
u8 data[2] = { MIPI_DSI_DCS_SET_TEAR_ON, mode };
struct mipi_dsi_msg msg;
if (!dsi-ops || !dsi-ops-transfer)
return -ENOSYS;
memset(msg, 0, sizeof(msg));
msg.channel = dsi-channel;
msg.type = MIPI_DSI_DCS_SHORT_WRITE_PARAM;
msg.tx_len = sizeof(data);
msg.tx_buf = data;
return dsi-ops-transfer(dsi-host, msg);
}
Thierry
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250
On Tue, Jul 29, 2014 at 11:17:10AM +0900, Chanwoo Choi wrote:
This patch add TMU (Thermal Management Unit) dt node to monitor the high
temperature for Exynos3250.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Eduardo Valentin edubez...@gmail.com
---
This patch has a dependency on following patch [1] which supporting the TMU
of Exynos3250:
[1]
https://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/commit/?h=nextid=1fe56dc16a3dab400206443f70ae158c8f595c42
Changes from v1:
- Remove duplicate 'interrupt-parent' property.
arch/arm/boot/dts/exynos3250.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 77a06df..41a260a 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -168,6 +168,15 @@
status = disabled;
};
+ tmu: tmu@100C {
+ compatible = samsung,exynos3250-tmu;
+ reg = 0x100C 0x100;
+ interrupts = 0 216 0;
+ clocks = cmu CLK_TMU_APBIF;
+ clock-names = tmu_apbif;
+ status = disabled;
+ };
+
gic: interrupt-controller@10481000 {
compatible = arm,cortex-a15-gic;
#interrupt-cells = 3;
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line 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: [v2] input: drv260x: Add TI drv260x haptics driver
Michal Thanks for the feedback On 07/29/2014 07:09 AM, Michal Malý wrote: On Monday 28 of July 2014 21:21:26 Murphy, Dan wrote: Dmitry On 07/28/2014 12:59 PM, si...@mungewell.org wrote: The initial driver supports the devices real time playback mode. But the device has additional wave patterns in ROM. As it presented the device appears to be a memoryless device, however you present it to the rest of the system as if it can support playback of multiple effects simultaneously, which is incorrect. My guess that you need to engage the memoryless input library to schedule handling multiple effects for your device, including ramping up, ramping down, stopping playback when effects runs out, etc. Hi Dan, Elias and Michal (cc'ed) are working on a kernel/userland library to handle sending multiple force feedback signals to 'simple' devices, perhaps you should engage with them. Simon Hi Dan, since I spent some time trying to improve the memoryless library I can hopefully provide you with some hints. If I'm reading this right, your device cannot play more than one effect at once but it can operate eihter in RTP mode where the user controls the operation of the motors directly on in an automated mode where the device follows some pre- programmed waveform. These two modes are mutually exclusive. Actually there is one other mode here, that is the ability to program in a waveform to be played. So that makes 3 modes I have to think about supporting. I know there are products out there that would like to and do customize their feedback based on certain user actions. For the custom mode I could use the FF_CUSTOM id but not sure how that fits into the Periodic structure. If I can get two out of 3 that would be great. If my understanding of the problem is correct, you will struggle both with memoryless library and your own imlementation. The memoryless library is quite simplistic and it doesn't have any sort of passthrough mode so you would not be able to do anything besides RTP that way. On the other hand if you decide to write your own implementation of effect handling you will end up duplicating a lot of code that already exists in the memoryless library and has been proven to work. A possible solution for the problem would be to separate the functions that control effect timing from the memoryless library and make them globally accessible. I believe that this would simplify any customized haptic implementation considerably and it might be a decent interim solution before the project Simon mentioned is ready. How far are you on finishing the project? If it is only a little bit out I can just keep with the memless RTP mode as a start and then implement the other functions once the solution is accepted. Dan If there is anybody interested in such a solution I can probably whip up a patch for it quite quickly. Regards, Michal -- -- Dan Murphy -- To unsubscribe from this list: send the line 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: [v2] input: drv260x: Add TI drv260x haptics driver
Mark
Thanks for the feedback
On 07/29/2014 04:37 AM, Mark Rutland wrote:
On Mon, Jul 28, 2014 at 05:53:23PM +0100, Dan Murphy wrote:
Add the TI drv260x haptics/vibrator driver.
This device uses the input force feedback
to produce a wave form to driver an
ERM or LRA actuator device.
The initial driver supports the devices
real time playback mode. But the device
has additional wave patterns in ROM.
This functionality will be added in
future patchsets.
Product data sheet is located here:
http://www.ti.com/product/drv2605
Signed-off-by: Dan Murphy dmur...@ti.com
---
v2 - Fixed binding doc and patch headline -
https://patchwork.kernel.org/patch/4619641/
.../devicetree/bindings/input/ti,drv260x.txt | 44 ++
drivers/input/misc/Kconfig |9 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/drv260x.c | 537
include/dt-bindings/input/ti-drv260x.h | 30 ++
include/linux/input/drv260x.h | 181 +++
6 files changed, 802 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt
create mode 100644 drivers/input/misc/drv260x.c
create mode 100644 include/dt-bindings/input/ti-drv260x.h
create mode 100644 include/linux/input/drv260x.h
diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt
b/Documentation/devicetree/bindings/input/ti,drv260x.txt
new file mode 100644
index 000..930429b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
@@ -0,0 +1,44 @@
+Texas Instruments - drv260x Haptics driver family
+
+The drv260x family serial control bus communicates through I2C protocols
+
+Required properties:
+ - compatible - One of:
+ ti,drv2604 - DRV2604
+ ti,drv2605 - DRV2605
+ ti,drv2605l - DRV2605L
+ - reg - I2C slave address
+ - mode - Power up mode of the chip (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_RTP_MODE - Real time playback mode
+ DRV260X_LRA_MODE - Linear Resonance Actuator mode
(Piezoelectric)
+ DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary
vibrator)
What exactly are these, and why does the kernel not decide?
The LRA and ERM are vibrator types. These are specific to the product and the
kernel cannot decide.
The kernel driver needs to be told what type of vibrator is connected. The
driver then
sets the voltages and other settings to drive the vibrator type safely. All
vibrators are dumb and do not
have IDs identifying themselves so there is no self discovery here.
RTP is not a vibrator type but just a mode you can place the device into. I
can probably remove that
and have the user space or driver take care of that setting.
+ - library_sel - Library to use at power up (defined in
include/dt-bindings/input/ti-drv260x.h)
Please s/_/-/ in all property names.
+ DRV260X_LIB_A - Pre-programmed Library
+ DRV260X_LIB_B - Pre-programmed Library
+ DRV260X_LIB_C - Pre-programmed Library
+ DRV260X_LIB_D - Pre-programmed Library
+ DRV260X_LIB_E - Pre-programmed Library
+ DRV260X_LIB_F - Pre-programmed Library
What exactly are these, and why does the kernel not decide?
+
+Optional properties:
+ - enable-gpio - gpio pin to enable/disable the device.
+ - vib_rated_voltage - The rated voltage of the actuator. If this is
not
+ set then the value will be
defaulted to 0x90 in the
+ driver.
What units is this in?
Good catch I was thinking this when I was writing the documentation but forgot
to add
it. I will fix the formatting here and below as well.
Don't mention the driver, just say if not 0x90 (but with a better
description of what 0x90 actually means).
OK
+ - vib_overdrive_voltage - The overdrive voltage of the actuator.
+ If this is not set
then the value
+ will be defaulted to
0x90 in the driver.
Similarly on both points.
[...]
Same as above as well
+static int drv260x_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct drv260x_data *haptics;
+ struct device_node *np = client-dev.of_node;
+ struct drv260x_platform_data *pdata = client-dev.platform_data;
+ struct ff_device *ff;
+ int ret;
+ int voltage;
+
+ haptics = devm_kzalloc(client-dev, sizeof(*haptics), GFP_KERNEL);
+ if (!haptics)
+ return -ENOMEM;
+
+ haptics-rated_voltage = DRV260X_DEF_OD_CLAMP_VOLT;
+ haptics-rated_voltage =
[PATCH 0/5] irqchip: New driver for ST's SysCfg controlled IRQs
This driver enabled IRQs which are controlled using System Configuration registers. Without it Performance Monitoring, Core Sight Tracing and some L2 Caches will fail to function. Lee Jones (5): irqchip: Supply new driver for STi based devices irqchip: irq-st: Add documentation for STi based syscfg IRQs ARM: STi: STiH416: Enable Cortex-A9 PMU support ARM: STi: STiH416: Enable PMU IRQs ARM: STI: Ensure requested STi's SysCfg Controlled IRQs are enabled at boot .../interrupt-controller/st,sti-irq-syscfg.txt | 35 arch/arm/boot/dts/stih416.dtsi | 16 ++ arch/arm/mach-sti/Kconfig | 1 + drivers/irqchip/Kconfig| 7 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-st.c | 204 + 6 files changed, 264 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt create mode 100644 drivers/irqchip/irq-st.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 4/6] ARM: STi: STiH416: Enable Cortex-A9 PMU support
This is ARM's generic Performance Monitoring Unit.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/stih416.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 84758d7..badefd6 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -21,6 +21,12 @@
cache-level = 2;
};
+ arm-pmu {
+ compatible = arm,cortex-a9-pmu;
+ interrupt-parent = intc;
+ interrupts = GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH;
+ };
+
soc {
#address-cells = 1;
#size-cells = 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 5/6] ARM: STi: STiH416: Enable PMU IRQs
This driver is used to enable System Configuration Register controlled
External, CTI (Core Sight), PMU (Performance Management), and PL310 L2
Cache IRQs prior to use.
Here we are enabling PMU IRQs on both channels.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/stih416.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index badefd6..7276125 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -11,6 +11,7 @@
#include stih416-pinctrl.dtsi
#include dt-bindings/interrupt-controller/arm-gic.h
#include dt-bindings/reset-controller/stih416-resets.h
+#include dt-bindings/interrupt-controller/irq-st.h
/ {
L2: cache-controller {
compatible = arm,pl310-cache;
@@ -27,6 +28,15 @@
interrupts = GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH;
};
+ irq-syscfg {
+ compatible= st,stih416-irq-syscfg;
+ st,syscfg = syscfg_cpu;
+ st,irq-device = ST_IRQ_SYSCFG_PMU_0,
+ ST_IRQ_SYSCFG_PMU_1;
+ st,fiq-device = ST_IRQ_SYSCFG_DISABLED,
+ ST_IRQ_SYSCFG_DISABLED;
+ };
+
soc {
#address-cells = 1;
#size-cells = 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 6/6] ARM: STI: Ensure requested STi's SysCfg Controlled IRQs are enabled at boot
This driver is used to enable System Configuration Register controlled External, CTI (Core Sight), PMU (Performance Management), and PL310 L2 Cache IRQs prior to use. Signed-off-by: Lee Jones lee.jo...@linaro.org --- arch/arm/mach-sti/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig index 878e9ec..eae0971 100644 --- a/arch/arm/mach-sti/Kconfig +++ b/arch/arm/mach-sti/Kconfig @@ -1,6 +1,7 @@ menuconfig ARCH_STI bool STMicroelectronics Consumer Electronics SOCs if ARCH_MULTI_V7 select ARM_GIC + select ST_IRQCHIP select ARM_GLOBAL_TIMER select PINCTRL select PINCTRL_ST -- 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: use IORESOURCE_REG resource type for non-translatable addresses in DT
Arnd, thanks for the comments.
On 07/29/2014 03:00 PM, Arnd Bergmann wrote:
On Tuesday 29 July 2014 14:42:31 Stanimir Varbanov wrote:
taddr = of_translate_address(dev, addrp);
- if (taddr == OF_BAD_ADDR)
- return -EINVAL;
+ /*
+* if the address is non-translatable to cpu physical address
+* fallback to a IORESOURCE_REG resource.
+*/
+ if (taddr == OF_BAD_ADDR) {
+ memset(r, 0, sizeof(*r));
+ taddr = of_read_number(addrp, 1);
+ if (taddr == OF_BAD_ADDR)
+ return -EINVAL;
+ r-start = taddr;
+ r-end = taddr + size - 1;
+ r-flags = IORESOURCE_REG;
+ r-name = name ? name : dev-full_name;
+ return 0;
+ }
+
I don't think that everything returning OF_BAD_ADDR makes sense
to turn into IORESOURCE_REG. It could be an e.g. invalid DT
representation, a node with #size-cells=0, or it could be
something that gets translated one or more nodes up in the
tree before it reaches a bus without a ranges property.
Also, you should not rely on #address-cells being hardcoded
to 1 above.
This was just an example. Of course it has many issues and probaly it is
wrong:) The main goal was to understand does IORESOURCE_REG resource
type and parsing the *reg* properties for non-translatable addresses are
feasible. And also does it acceptable by community and OF platform
maintainers.
How about modifying of_get_address() rather than
__of_address_to_resource() instead? You could introduce
a new of_bus entry for each bus you expect to return
an IORESOURCE_REG, or you could change of_bus_default_get_flags
to return IORESOURCE_REG if the parent node has no ranges property
and is not the root node.
IMO the clearer solution is to introduce a new of_bus bus. In that case
one possible problem will be how to distinguish the non-translatable and
the other buses. Also the *device_type* property is deprecated for non
PCI devices.
The second option will need to change the prototype of .get_flags method
to receive device_node structure.
Thoughts?
--
regards,
Stan
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] irqchip: irq-st: Add documentation for STi based syscfg IRQs
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
.../interrupt-controller/st,sti-irq-syscfg.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
b/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
new file mode 100644
index 000..ced6014
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
@@ -0,0 +1,35 @@
+STMicroelectronics STi System Configuration Controlled IRQs
+---
+
+On STi based systems; External, CTI (Core Sight), PMU (Performance Management),
+and PL310 L2 Cache IRQs are controlled using System Configuration registers.
+This driver is used to unmask them prior to use.
+
+Required properties:
+- compatible : Should be set to one of:
+ st,stih415-irq-syscfg
+ st,stih416-irq-syscfg
+ st,stih407-irq-syscfg
+ st,stid127-irq-syscfg
+- st,syscfg: Phandle to Cortex-A9 IRQ system config registers
+- st,irq-device: Array of IRQs to enable - should be 2 in length
+- st,fiq-device: Array of FIQs to enable - should be 2 in length
+
+Optional properties:
+- st,invert-ext: External IRQs can be inverted at will. This property
inverts
+ these IRQs using bitwise logic. A number of defines have been
+ provided for convenience:
+ ST_IRQ_SYSCFG_EXT_1_INV
+ ST_IRQ_SYSCFG_EXT_2_INV
+ ST_IRQ_SYSCFG_EXT_3_INV
+Example:
+
+irq-syscfg {
+ compatible= st,stih416-irq-syscfg;
+ st,syscfg = syscfg_cpu;
+ st,irq-device = ST_IRQ_SYSCFG_PMU_0,
+ ST_IRQ_SYSCFG_PMU_1;
+ st,fiq-device = ST_IRQ_SYSCFG_DISABLED,
+ ST_IRQ_SYSCFG_DISABLED;
+ st,invert-ext = (ST_IRQ_SYSCFG_EXT_1_INV | ST_IRQ_SYSCFG_EXT_3_INV);
+};
--
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 1/6] dt: bindings: Supply shared ST IRQ defines
These defines are used to allow values used for configuration to be easily human readable and will lessen the chance of logical mistakes. Signed-off-by: Lee Jones lee.jo...@linaro.org --- include/dt-bindings/interrupt-controller/irq-st.h | 30 +++ 1 file changed, 30 insertions(+) create mode 100644 include/dt-bindings/interrupt-controller/irq-st.h diff --git a/include/dt-bindings/interrupt-controller/irq-st.h b/include/dt-bindings/interrupt-controller/irq-st.h new file mode 100644 index 000..4c59ace --- /dev/null +++ b/include/dt-bindings/interrupt-controller/irq-st.h @@ -0,0 +1,30 @@ +/* + * include/linux/irqchip/irq-st.h + * + * Copyright (C) 2014 STMicroelectronics – All Rights Reserved + * + * Author: Lee Jones lee.jo...@linaro.org + * + * 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. + */ + +#ifndef _DT_BINDINGS_INTERRUPT_CONTROLLER_ST_H +#define _DT_BINDINGS_INTERRUPT_CONTROLLER_ST_H + +#define ST_IRQ_SYSCFG_EXT_00 +#define ST_IRQ_SYSCFG_EXT_11 +#define ST_IRQ_SYSCFG_EXT_22 +#define ST_IRQ_SYSCFG_CTI_03 +#define ST_IRQ_SYSCFG_CTI_14 +#define ST_IRQ_SYSCFG_PMU_05 +#define ST_IRQ_SYSCFG_PMU_16 +#define ST_IRQ_SYSCFG_pl310_L2 7 +#define ST_IRQ_SYSCFG_DISABLED 0x + +#define ST_IRQ_SYSCFG_EXT_1_INV0x1 +#define ST_IRQ_SYSCFG_EXT_2_INV0x2 +#define ST_IRQ_SYSCFG_EXT_3_INV0x4 + +#endif -- 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 2/6] irqchip: Supply new driver for STi based devices
This driver is used to enable System Configuration Register controlled
External, CTI (Core Sight), PMU (Performance Management), and PL310 L2
Cache IRQs prior to use.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
drivers/irqchip/Kconfig | 7 ++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-st.c | 206 +++
3 files changed, 214 insertions(+)
create mode 100644 drivers/irqchip/irq-st.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index bbb746e..7252de9 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -91,3 +91,10 @@ config IRQ_CROSSBAR
The primary irqchip invokes the crossbar's callback which inturn
allocates
a free irq and configures the IP. Thus the peripheral interrupts are
routed to one of the free irqchip interrupt lines.
+
+config ST_IRQCHIP
+ bool
+ select REGMAP
+ select MFD_SYSCON
+ help
+ Enables SysCfg Controlled IRQs on STi based platforms.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 62a13e5..f859c14 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_XTENSA) += irq-xtensa-pic.o
obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
+obj-$(CONFIG_ST_IRQCHIP) += irq-st.o
diff --git a/drivers/irqchip/irq-st.c b/drivers/irqchip/irq-st.c
new file mode 100644
index 000..f31126f
--- /dev/null
+++ b/drivers/irqchip/irq-st.c
@@ -0,0 +1,206 @@
+/*
+ * drivers/irqchip/irq-st.c
+ *
+ * Copyright (C) 2014 STMicroelectronics – All Rights Reserved
+ *
+ * Author: Lee Jones lee.jo...@linaro.org
+ *
+ * This is a re-write of Christophe Kerello's PMU driver.
+ *
+ * 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 dt-bindings/interrupt-controller/irq-st.h
+#include linux/err.h
+#include linux/mfd/syscon.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/slab.h
+
+#define STIH415_SYSCFG_642 0x0a8
+#define STIH416_SYSCFG_75430x87c
+#define STIH407_SYSCFG_51020x198
+#define STID127_SYSCFG_734 0x088
+
+#define ST_A9_IRQ_MASK 0x001F
+#define ST_A9_IRQ_MAX_CHANS2
+
+#define ST_A9_IRQ_EN_CTI_0 BIT(0)
+#define ST_A9_IRQ_EN_CTI_1 BIT(1)
+#define ST_A9_IRQ_EN_PMU_0 BIT(2)
+#define ST_A9_IRQ_EN_PMU_1 BIT(3)
+#define ST_A9_IRQ_EN_pl310_L2 BIT(4)
+#define ST_A9_IRQ_EN_EXT_0 BIT(5)
+#define ST_A9_IRQ_EN_EXT_1 BIT(6)
+#define ST_A9_IRQ_EN_EXT_2 BIT(7)
+
+#define ST_A9_FIQ_N_SEL(dev, chan) (dev (8 + (chan * 3)))
+#define ST_A9_IRQ_N_SEL(dev, chan) (dev (14 + (chan * 3)))
+#define ST_A9_EXTIRQ_INV_SEL(dev) (dev 20)
+
+struct st_irq_syscfg {
+ struct regmap *regmap;
+ unsigned int syscfg;
+ unsigned int result;
+ bool ext_inverted;
+};
+
+static const struct of_device_id st_irq_syscfg_match[] = {
+ {
+ .compatible = st,stih415-irq-syscfg,
+ .data = (void *)STIH415_SYSCFG_642,
+ },
+ {
+ .compatible = st,stih416-irq-syscfg,
+ .data = (void *)STIH416_SYSCFG_7543,
+ },
+ {
+ .compatible = st,stih407-irq-syscfg,
+ .data = (void *)STIH407_SYSCFG_5102,
+ },
+ {
+ .compatible = st,stid127-irq-syscfg,
+ .data = (void *)STID127_SYSCFG_734,
+ },
+ {}
+};
+
+static int st_irq_xlate(struct platform_device *pdev,
+ int device, int channel, bool irq)
+{
+ struct st_irq_syscfg *ddata = dev_get_drvdata(pdev-dev);
+
+ /* Set the device enable bit. */
+ switch (device) {
+ case ST_IRQ_SYSCFG_EXT_0 :
+ ddata-result |= ST_A9_IRQ_EN_EXT_0;
+ break;
+ case ST_IRQ_SYSCFG_EXT_1 :
+ ddata-result |= ST_A9_IRQ_EN_EXT_1;
+ break;
+ case ST_IRQ_SYSCFG_EXT_2 :
+ ddata-result |= ST_A9_IRQ_EN_EXT_2;
+ break;
+ case ST_IRQ_SYSCFG_CTI_0 :
+ ddata-result |= ST_A9_IRQ_EN_CTI_0;
+ break;
+ case ST_IRQ_SYSCFG_CTI_1 :
+ ddata-result |= ST_A9_IRQ_EN_CTI_1;
+ break;
+ case ST_IRQ_SYSCFG_PMU_0 :
+ ddata-result |= ST_A9_IRQ_EN_PMU_0;
+ break;
+ case ST_IRQ_SYSCFG_PMU_1 :
+ ddata-result |= ST_A9_IRQ_EN_PMU_1;
+ break;
+ case ST_IRQ_SYSCFG_pl310_L2 :
+ ddata-result |= ST_A9_IRQ_EN_pl310_L2;
+
Re: [PATCH 3/3] arm: dts: Add gta04a5 model
Hello, On Tue, Jul 29, 2014 at 3:03 PM, Dr. H. Nikolaus Schaller h...@goldelico.com wrote: Hi, So what's the conclusion? Are changes needed to this patch series or not? I advocate that no changes are needed. I agree with Dr. H. Nikolaus on this regard. A DeviceTree should be a description of the hardware and if two hardware platforms differs, then we need two different DTS. Lately I'm seeing some attempts to abuse u-boot's fdt command, u-boot should only modify the strictly necessary like the /chosen branch. Allowing u-boot to mangle the FDT before passing to the kernel just to avoid some DT duplication doesn't sound like a good idea IMHO. BR, Nikolaus -- 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 30/35] irqchip: add irq-omap-intc.h header
On Tue, Jul 29, 2014 at 05:01:33AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140728 14:19]: OMAP INTC irqchip driver will be moved under drivers/irqchip/ soon but we still have a dependency with mach-omap2 when it comes to idle functions. In order to make it easy to share those function prototypes with OMAP PM code, we introduce this new header. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap2/board-3430sdp.c| 1 + arch/arm/mach-omap2/board-am3517crane.c| 1 + arch/arm/mach-omap2/board-am3517evm.c | 1 + arch/arm/mach-omap2/board-cm-t35.c | 1 + arch/arm/mach-omap2/board-cm-t3517.c | 1 + arch/arm/mach-omap2/board-devkit8000.c | 1 + arch/arm/mach-omap2/board-ldp.c| 1 + arch/arm/mach-omap2/board-omap3beagle.c| 1 + arch/arm/mach-omap2/board-omap3logic.c | 1 + arch/arm/mach-omap2/board-omap3pandora.c | 1 + arch/arm/mach-omap2/board-omap3stalker.c | 1 + arch/arm/mach-omap2/board-omap3touchbook.c | 1 + arch/arm/mach-omap2/board-overo.c | 1 + arch/arm/mach-omap2/board-rx51.c | 1 + arch/arm/mach-omap2/board-ti8168evm.c | 1 + arch/arm/mach-omap2/common.h | 9 - arch/arm/mach-omap2/cpuidle34xx.c | 1 + arch/arm/mach-omap2/irq.c | 1 + arch/arm/mach-omap2/pm24xx.c | 1 + arch/arm/mach-omap2/pm34xx.c | 1 + include/linux/irqchip/irq-omap-intc.h | 32 ++ ... +void omap2_init_irq(void); +void omap3_init_irq(void); +void ti81xx_init_irq(void); I think these will all go away with DT based booting? So it might be worth waiting for that rather than churn all these files, or.. you just asked me to rebase this series because now we had OMAP3 idle working with DT. And now, you're asking me to hold on to this series because not everything is DT-based yet. This is the third time I rebase the series after a long hiatus and it always comes out to the same result - let's wait some more. -- balbi signature.asc Description: Digital signature
Re: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain
Hi, On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140728 14:19]: now that we don't need to support legacy board-files, we can completely switch over to a linear irq domain and make use of irq_alloc_domain_generic_chips() to allocate all generic irq chips for us. This patch seems to somehow break off-idle for omap3 where it no longer wakes up. Sure your bisection is correct ? This patch just switches from legacy irq domain to linear irq domain. Other than that, this whole series boots fine for me. good -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 2/2] pwm: add this patch to support the new pwm of Rockchip SoCs
Thierry,
在 2014年07月29日 19:38, Thierry Reding 写道:
On Tue, Jul 29, 2014 at 07:09:07PM +0800, caesar wrote:
Thierry,
在 2014年07月29日 18:22, Thierry Reding 写道:
On Mon, Jul 28, 2014 at 07:19:18PM +0800, caesar wrote:
Doug,
在 2014年07月28日 12:01, Doug Anderson 写道:
Caesar,
On Sun, Jul 27, 2014 at 7:00 AM, caesar caesar.w...@rock-chips.com wrote:
/*I think will be show the faill log:-
* rockchip-pwm ff9301a0.pwm: can't request region for resource [mem
0xff9301a0-0xff93019f]
*/
pc-base = devm_ioremap_resource(dev, regs);
Did you actually code this up and try it and get this error?
Yeah.
This should work if you properly set up the PWM subregion as a child of
the LCDC region, which is what MFD will do for you.
Thierry
As you say,should this change be occured by lcdc driver and dts?
The PWM driver don't need do any changes?
No, I don't think the PWM driver needs to be changed for the above to
work.
Thierry
Ok, as you suggestions, The PWM driver :
static int rockchip_pwm_probe (...)
{
...
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- pc-base = devm_ioremap_resource(pdev-dev, r);
+ if (!strcmp(of_id-compatible, rockchip,vop-pwm))
+ pc-base = devm_ioremap(pdev-dev, r-start,
resource_size(r));
+ else
+ pc-base = devm_ioremap_resource(pdev-dev, r);
...
}
This will be fixed for following:
static int rockchip_pwm_probe (...)
{
...
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pc-base = devm_ioremap_resource(pdev-dev, r);
...
}
I will discuss with lcdc of upstream's people tomorrow.
I has sent the PWM in patch v4 the last few days,Hope you can help check
and accept it,thanks.:-)
-caesar
--
To unsubscribe from this list: send the line 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 0/4]ata: Fixes related to APM X-Gene SATA host controller driver.
On Tue, Jul 29, 2014 at 12:24:48PM +0530, Suman Tripathi wrote: This patch set contains a couple of fixes related to APM X-Gene SATA controller driver. v2 Change: 1. Drop the Link down retry patch from this patch set. v4 Change: 1. Drop the patch to fix the csr-mask in dts for PHY clock node of SATA Host Controller 1. 2. Add the patch to correct the OOB tunning parameters for the COMINIT/COMWAKE parameters. 3. Add the patch to remove the NCQ support from the APM X-Gene AHCI SATA Host controller driver. 4. Add the patch to remove the clock and PHY reference nodes from the APM X-Gene Host controller dts node. Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com Applied 1 and 3 to libata/for-3.17. 4 doesn't apply. Also, please prefix the patches with ahci_xgene: from now on. Thanks. -- tejun -- To unsubscribe from this list: send the line 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 0/4]ata: Fixes related to APM X-Gene SATA host controller driver.
On Tue, Jul 29, 2014 at 08:05:45PM +0530, Suman Tripathi wrote: Hi, Applied 1 and 3 to libata/for-3.17. 4 doesn't apply. Also, please prefix the patches with ahci_xgene: from now on. [suman] : You mean the Remove NCQ patch is not applied. Any reason for that ? I meant that the patch doesn't apply to libata/for-3.17. Please always generate patches against the current devel branch. Thanks. -- tejun -- To unsubscribe from this list: send the line 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: [v2] input: drv260x: Add TI drv260x haptics driver
On Tue, Jul 29, 2014 at 02:50:48PM +0100, Murphy, Dan wrote: Mark Thanks for the feedback On 07/29/2014 04:37 AM, Mark Rutland wrote: On Mon, Jul 28, 2014 at 05:53:23PM +0100, Dan Murphy wrote: Add the TI drv260x haptics/vibrator driver. This device uses the input force feedback to produce a wave form to driver an ERM or LRA actuator device. The initial driver supports the devices real time playback mode. But the device has additional wave patterns in ROM. This functionality will be added in future patchsets. Product data sheet is located here: http://www.ti.com/product/drv2605 Signed-off-by: Dan Murphy dmur...@ti.com --- v2 - Fixed binding doc and patch headline - https://patchwork.kernel.org/patch/4619641/ .../devicetree/bindings/input/ti,drv260x.txt | 44 ++ drivers/input/misc/Kconfig |9 + drivers/input/misc/Makefile|1 + drivers/input/misc/drv260x.c | 537 include/dt-bindings/input/ti-drv260x.h | 30 ++ include/linux/input/drv260x.h | 181 +++ 6 files changed, 802 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt create mode 100644 drivers/input/misc/drv260x.c create mode 100644 include/dt-bindings/input/ti-drv260x.h create mode 100644 include/linux/input/drv260x.h diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt b/Documentation/devicetree/bindings/input/ti,drv260x.txt new file mode 100644 index 000..930429b --- /dev/null +++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt @@ -0,0 +1,44 @@ +Texas Instruments - drv260x Haptics driver family + +The drv260x family serial control bus communicates through I2C protocols + +Required properties: + - compatible - One of: + ti,drv2604 - DRV2604 + ti,drv2605 - DRV2605 + ti,drv2605l - DRV2605L + - reg - I2C slave address + - mode - Power up mode of the chip (defined in include/dt-bindings/input/ti-drv260x.h) + DRV260X_RTP_MODE - Real time playback mode + DRV260X_LRA_MODE - Linear Resonance Actuator mode (Piezoelectric) + DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary vibrator) What exactly are these, and why does the kernel not decide? The LRA and ERM are vibrator types. These are specific to the product and the kernel cannot decide. The kernel driver needs to be told what type of vibrator is connected. The driver then sets the voltages and other settings to drive the vibrator type safely. All vibrators are dumb and do not have IDs identifying themselves so there is no self discovery here. I see. That makes sense, thanks for the description. It might make more sense to call this vibrator-type, rather than mode, but otherwise this should be ok. In the past I've asked for strings rather than magic numbers, but I'll leave that choice to you. RTP is not a vibrator type but just a mode you can place the device into. I can probably remove that and have the user space or driver take care of that setting. Ok, that sounds good to me. + - library_sel - Library to use at power up (defined in include/dt-bindings/input/ti-drv260x.h) Please s/_/-/ in all property names. + DRV260X_LIB_A - Pre-programmed Library + DRV260X_LIB_B - Pre-programmed Library + DRV260X_LIB_C - Pre-programmed Library + DRV260X_LIB_D - Pre-programmed Library + DRV260X_LIB_E - Pre-programmed Library + DRV260X_LIB_F - Pre-programmed Library What exactly are these, and why does the kernel not decide? + +Optional properties: + - enable-gpio - gpio pin to enable/disable the device. + - vib_rated_voltage - The rated voltage of the actuator. If this is not + set then the value will be defaulted to 0x90 in the + driver. What units is this in? Good catch I was thinking this when I was writing the documentation but forgot to add it. I will fix the formatting here and below as well. Cheers. Mark. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: dts: exynos5250: Fold common ChromeOS parts into Snow
Hello Andreas, On Tue, Jul 29, 2014 at 3:00 PM, Andreas Färber afaer...@suse.de wrote: Hi Javier and Doug, Hm, in different context it was stated that device trees shouldn't rely on bootloader behavior (for a /memory node on Zynq we ended up specifying the size cell with the real value despite U-Boot overriding it to a lesser value). Well is not strictly the same, the memory node is a hardware description while the chosen node is one of those exceptional nodes that don't represent a real device. Also the usage for the memory node is marked as required in ePAR while the later is marked as optional. Can we instead settle on filling this node with defaults? :) bootargs = console=tty1; would be my choice for Spring. Would that be applicable for Snow as well? Not sure how to specify that via linux,stdout-path property. I believe this would be a follow-up patch either way. Since there's at least two series out there trying to fiddle with -cros-common.dtsi, including one that drops the slot sub-node of the MMC and one that adds CPU power supply, it would be nice if we can get the -cros-common parts sorted out and applied. Can you ack/review 1-2? Should I squash them in a v3? A sensible default makes sense to me and yes it should be a follow-up patch anyways. Thanks, Andreas -- 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 v11 3/8] ata: libahci_platform: move port_map parameters into the AHCI structure
A couple nit picks.
On Thu, Jul 24, 2014 at 11:17:25AM +0200, Antoine Ténart wrote:
@@ -321,6 +321,8 @@ struct ahci_host_priv {
u32 cap;/* cap to use */
u32 cap2; /* cap2 to use */
u32 port_map; /* port map to use */
+ u32 force_port_map; /* force port map */
+ u32 mask_port_map; /* mask out particular bits */
Let's collect the inputs, including flags, at the top and mark them clearly.
int ahci_platform_init_host(struct platform_device *pdev,
struct ahci_host_priv *hpriv,
const struct ata_port_info *pi_template,
- unsigned long host_flags,
- unsigned int force_port_map,
- unsigned int mask_port_map)
+ unsigned long host_flags)
This doesn't make much sense to me. Near the head of the function, it
does
hpriv-flags |= host_flags;
Wouldn't it make more sense to just let the caller set hpriv-flags?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 RESEND 2/4] drivers: of: initialize and assign reserved memory to newly created devices
Hello, On 2014-07-28 16:17, Grant Likely wrote: On Mon, 14 Jul 2014 10:28:05 +0200, Marek Szyprowski m.szyprow...@samsung.com wrote: Use recently introduced of_reserved_mem_device_init() function to automatically assign respective reserved memory region to the newly created platform and amba device. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com I'm still not okay with this patch. I don't think it is appropriate to add the hook into the generic path that gets used for every platform device. The devices that need reserved memory should explicitly request it, and any setup be done at that time. Okay... I thought that it will be easier to have it done in generic code, if You don't think so, then I give up and we will add it in all drivers requiring such memory regions. What about patch 3/4 and 4/4? Would it be possible to have your ack to get them merged? Right now patch 4/4 depends on changes from akpm tree, so it will be best to merge them to akpm tree. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] tty: omap-serial: prevent division by zero
Sorry, missed some CC's in git send-email.
On Tue, Jul 29, 2014 at 04:52:55PM +0200, Frans Klaver wrote:
If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n13 and n16 values in serial_omap_baud_is_mode16 may become
0. This causes a division by zero when calculating the difference
between calculated and desired baud rates. To prevent this, cap n13 and
n16 on 1.
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
drivers/tty/serial/omap-serial.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index d017cec..e454b7c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -254,8 +254,16 @@ serial_omap_baud_is_mode16(struct uart_port *port,
unsigned int baud)
{
unsigned int n13 = port-uartclk / (13 * baud);
unsigned int n16 = port-uartclk / (16 * baud);
- int baudAbsDiff13 = baud - (port-uartclk / (13 * n13));
- int baudAbsDiff16 = baud - (port-uartclk / (16 * n16));
+ int baudAbsDiff13;
+ int baudAbsDiff16;
+
+ if (n13 == 0)
+ n13 = 1;
+ if (n16 == 0)
+ n16 = 1;
+
+ baudAbsDiff13 = baud - (port-uartclk / (13 * n13));
+ baudAbsDiff16 = baud - (port-uartclk / (16 * n16));
if (baudAbsDiff13 0)
baudAbsDiff13 = -baudAbsDiff13;
if (baudAbsDiff16 0)
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] tty: omap-serial: use threaded interrupt handler
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.
In practice this therefore reduces the need for hardware flow control,
meaning the sending side doesn't have to buffer as much either.
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
drivers/tty/serial/omap-serial.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index e454b7c..ff2d931 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -569,6 +569,21 @@ static void serial_omap_rdi(struct uart_omap_port *up,
unsigned int lsr)
}
/**
+ * serial_omap_fast_irq() - schedule interrupt handling
+ */
+static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
+{
+ struct uart_omap_port *up = dev_id;
+ unsigned int iir = serial_in(up, UART_IIR);
+ if (iir UART_IIR_NO_INT) {
+ return IRQ_NONE;
+ }
+
+ disable_irq_nosync(up-port.irq);
+ return IRQ_WAKE_THREAD;
+}
+
+/**
* serial_omap_irq() - This handles the interrupt from one port
* @irq: uart port irq number
* @dev_id: uart port info
@@ -578,18 +593,12 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
struct uart_omap_port *up = dev_id;
unsigned int iir, lsr;
unsigned int type;
- irqreturn_t ret = IRQ_NONE;
int max_count = 256;
spin_lock(up-port.lock);
pm_runtime_get_sync(up-dev);
do {
- iir = serial_in(up, UART_IIR);
- if (iir UART_IIR_NO_INT)
- break;
-
- ret = IRQ_HANDLED;
lsr = serial_in(up, UART_LSR);
/* extract IRQ type from IIR register */
@@ -618,17 +627,21 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
default:
break;
}
+
+ iir = serial_in(up, UART_IIR);
} while (!(iir UART_IIR_NO_INT) max_count--);
spin_unlock(up-port.lock);
tty_flip_buffer_push(up-port.state-port);
+ enable_irq(up-port.irq);
+
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
up-port_activity = jiffies;
- return ret;
+ return IRQ_HANDLED;
}
static unsigned int serial_omap_tx_empty(struct uart_port *port)
@@ -725,15 +738,17 @@ static int serial_omap_startup(struct uart_port *port)
/*
* Allocate the IRQ
*/
- retval = request_irq(up-port.irq, serial_omap_irq, up-port.irqflags,
- up-name, up);
+ retval = request_threaded_irq(up-port.irq, serial_omap_fast_irq,
+ serial_omap_irq, up-port.irqflags,
+ up-name, up);
if (retval)
return retval;
/* Optional wake-up IRQ */
if (up-wakeirq) {
- retval = request_irq(up-wakeirq, serial_omap_irq,
-up-port.irqflags, up-name, up);
+ retval = request_threaded_irq(up-wakeirq, serial_omap_fast_irq,
+ serial_omap_irq, up-port.irqflags,
+ up-name, up);
if (retval) {
free_irq(up-port.irq, up);
return retval;
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] tty: omap-serial: prevent division by zero
If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n13 and n16 values in serial_omap_baud_is_mode16 may become
0. This causes a division by zero when calculating the difference
between calculated and desired baud rates. To prevent this, cap n13 and
n16 on 1.
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
drivers/tty/serial/omap-serial.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d017cec..e454b7c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -254,8 +254,16 @@ serial_omap_baud_is_mode16(struct uart_port *port,
unsigned int baud)
{
unsigned int n13 = port-uartclk / (13 * baud);
unsigned int n16 = port-uartclk / (16 * baud);
- int baudAbsDiff13 = baud - (port-uartclk / (13 * n13));
- int baudAbsDiff16 = baud - (port-uartclk / (16 * n16));
+ int baudAbsDiff13;
+ int baudAbsDiff16;
+
+ if (n13 == 0)
+ n13 = 1;
+ if (n16 == 0)
+ n16 = 1;
+
+ baudAbsDiff13 = baud - (port-uartclk / (13 * n13));
+ baudAbsDiff16 = baud - (port-uartclk / (16 * n16));
if (baudAbsDiff13 0)
baudAbsDiff13 = -baudAbsDiff13;
if (baudAbsDiff16 0)
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/3] omap-serial high-speed fixes/improvements
Hi, Apologies, something went wrong. Here's a resend. Here's a couple of patches that should improve the behavior of the omap serial driver at high data rates and baud rates. I was actually surprised to see that proper dma support isn't there yet, but there you go. Anyone got news on that, by the way? Thanks for reviewing this, Frans Frans Klaver (3): tty: omap-serial: prevent division by zero tty: omap-serial: use threaded interrupt handler tty: omap-serial: support setting of hardware flow control in dts .../devicetree/bindings/serial/omap_serial.txt | 1 + drivers/tty/serial/omap-serial.c | 52 -- 2 files changed, 40 insertions(+), 13 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] tty: omap-serial: support setting of hardware flow control in dts
This makes hardware flow control availability configurable from the
device tree.
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
drivers/tty/serial/omap-serial.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..1b629e9 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -8,3 +8,4 @@ Required properties:
Optional properties:
- clock-frequency : frequency of the clock input to the UART
+- has-hw-flow-control : the hardware has flow control capability
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ff2d931..87df0ee 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1660,6 +1660,9 @@ static int serial_omap_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
wakeirq = irq_of_parse_and_map(pdev-dev.of_node, 1);
omap_up_info = of_get_uart_port_info(pdev-dev);
+ if (of_property_read_bool(pdev-dev.of_node,
+ has-hw-flow-control))
+ omap_up_info-flags |= UPF_HARD_FLOW;
pdev-dev.platform_data = omap_up_info;
} else {
uartirq = platform_get_irq(pdev, 0);
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/3] omap-serial high-speed fixes/improvements
Hi, Here's a couple of patches that should improve the behavior of the omap serial driver at high data rates and baud rates. I was actually surprised to see that proper dma support isn't there yet, but there you go. Anyone got news on that, by the way? Thanks for reviewing this, Frans Frans Klaver (3): tty: omap-serial: prevent division by zero tty: omap-serial: use threaded interrupt handler tty: omap-serial: support setting of hardware flow control in dts .../devicetree/bindings/serial/omap_serial.txt | 1 + drivers/tty/serial/omap-serial.c | 52 -- 2 files changed, 40 insertions(+), 13 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 30/35] irqchip: add irq-omap-intc.h header
* Felipe Balbi ba...@ti.com [140729 07:13]: On Tue, Jul 29, 2014 at 05:01:33AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140728 14:19]: OMAP INTC irqchip driver will be moved under drivers/irqchip/ soon but we still have a dependency with mach-omap2 when it comes to idle functions. In order to make it easy to share those function prototypes with OMAP PM code, we introduce this new header. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap2/board-3430sdp.c| 1 + arch/arm/mach-omap2/board-am3517crane.c| 1 + arch/arm/mach-omap2/board-am3517evm.c | 1 + arch/arm/mach-omap2/board-cm-t35.c | 1 + arch/arm/mach-omap2/board-cm-t3517.c | 1 + arch/arm/mach-omap2/board-devkit8000.c | 1 + arch/arm/mach-omap2/board-ldp.c| 1 + arch/arm/mach-omap2/board-omap3beagle.c| 1 + arch/arm/mach-omap2/board-omap3logic.c | 1 + arch/arm/mach-omap2/board-omap3pandora.c | 1 + arch/arm/mach-omap2/board-omap3stalker.c | 1 + arch/arm/mach-omap2/board-omap3touchbook.c | 1 + arch/arm/mach-omap2/board-overo.c | 1 + arch/arm/mach-omap2/board-rx51.c | 1 + arch/arm/mach-omap2/board-ti8168evm.c | 1 + arch/arm/mach-omap2/common.h | 9 - arch/arm/mach-omap2/cpuidle34xx.c | 1 + arch/arm/mach-omap2/irq.c | 1 + arch/arm/mach-omap2/pm24xx.c | 1 + arch/arm/mach-omap2/pm34xx.c | 1 + include/linux/irqchip/irq-omap-intc.h | 32 ++ ... +void omap2_init_irq(void); +void omap3_init_irq(void); +void ti81xx_init_irq(void); I think these will all go away with DT based booting? So it might be worth waiting for that rather than churn all these files, or.. you just asked me to rebase this series because now we had OMAP3 idle working with DT. And now, you're asking me to hold on to this series because not everything is DT-based yet. I just don't like the idea of patching all these board files that are going away anyways. If we need to do that, let's just add it to common.h that's already included by all the remaining board-*.c files. I know we should rather include the files directly, but in this case that's just extra churn. The real problem is how to properly deal with the save and restore calls that idle code needs. In any case, it seems we can merge quite a bit of this series already and then deal with the problem parts. This is the third time I rebase the series after a long hiatus and it always comes out to the same result - let's wait some more. Nope, it's always been this series causes PM regressions and few other minor comments. And we have not been in any position to really test that until with v3.16-rc4. And then you always run out of time and nobody else does anything :) Regards, Tony -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: dts: exynos5250: Fold common ChromeOS parts into Snow
Andreas,
On Tue, Jul 29, 2014 at 5:45 AM, Andreas Färber afaer...@suse.de wrote:
Doug,
Am 25.07.2014 18:02, schrieb Doug Anderson:
On Fri, Jul 18, 2014 at 10:20 AM, Andreas Färber afaer...@suse.de wrote:
+/*
+ * On Snow we've got SIP WiFi and so can keep drive strengths low to
+ * reduce EMI.
+ */
+mmc_3 {
+ status = okay;
+ num-slots = 1;
+ supports-highspeed;
+ broken-cd;
+ card-detect-delay = 200;
+ samsung,dw-mshc-ciu-div = 3;
+ samsung,dw-mshc-sdr-timing = 2 3;
+ samsung,dw-mshc-ddr-timing = 1 2;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 4;
+ pinctrl-names = default;
+ pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
This actually looks like a bug on snow. I don't think these pinctrl
statements are taking effect and I think they belong at the mmc level,
not the slot level. That's not a new bug introduced by you, though.
Mind fixing it? You've already got it right for Spring mmc_1.
I was taught never to mix code movements with functional changes, as it
hides them even if mentioned in the commit message. Would you like me to
fix it pre- or post-move? Post-move would be easiest for me. ;)
Agreed. Sorry for implying that it belonged as part of this patch.
I'd be happy if it was somewhere in the series, ideally before you
introduce the Spring device tree so diffs are cleaner for it. I don't
care if it's pre-move or post-move.
-Doug
--
To unsubscribe from this list: send the line 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 30/35] irqchip: add irq-omap-intc.h header
On Tue, Jul 29, 2014 at 08:06:55AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 07:13]: On Tue, Jul 29, 2014 at 05:01:33AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140728 14:19]: OMAP INTC irqchip driver will be moved under drivers/irqchip/ soon but we still have a dependency with mach-omap2 when it comes to idle functions. In order to make it easy to share those function prototypes with OMAP PM code, we introduce this new header. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap2/board-3430sdp.c| 1 + arch/arm/mach-omap2/board-am3517crane.c| 1 + arch/arm/mach-omap2/board-am3517evm.c | 1 + arch/arm/mach-omap2/board-cm-t35.c | 1 + arch/arm/mach-omap2/board-cm-t3517.c | 1 + arch/arm/mach-omap2/board-devkit8000.c | 1 + arch/arm/mach-omap2/board-ldp.c| 1 + arch/arm/mach-omap2/board-omap3beagle.c| 1 + arch/arm/mach-omap2/board-omap3logic.c | 1 + arch/arm/mach-omap2/board-omap3pandora.c | 1 + arch/arm/mach-omap2/board-omap3stalker.c | 1 + arch/arm/mach-omap2/board-omap3touchbook.c | 1 + arch/arm/mach-omap2/board-overo.c | 1 + arch/arm/mach-omap2/board-rx51.c | 1 + arch/arm/mach-omap2/board-ti8168evm.c | 1 + arch/arm/mach-omap2/common.h | 9 - arch/arm/mach-omap2/cpuidle34xx.c | 1 + arch/arm/mach-omap2/irq.c | 1 + arch/arm/mach-omap2/pm24xx.c | 1 + arch/arm/mach-omap2/pm34xx.c | 1 + include/linux/irqchip/irq-omap-intc.h | 32 ++ ... +void omap2_init_irq(void); +void omap3_init_irq(void); +void ti81xx_init_irq(void); I think these will all go away with DT based booting? So it might be worth waiting for that rather than churn all these files, or.. you just asked me to rebase this series because now we had OMAP3 idle working with DT. And now, you're asking me to hold on to this series because not everything is DT-based yet. I just don't like the idea of patching all these board files that are going away anyways. If we need to do that, let's just add it when are they going away ? Are we really gonna delay this series until those board-files eventually vanish ? to common.h that's already included by all the remaining board-*.c files. I know we should rather include the files directly, but in this case that's just extra churn. The real problem is how to properly deal with the save and restore calls that idle code needs. well, for system sleep we have callbacks from irq generic itself. The real problem is just with runtime PM. In any case, it seems we can merge quite a bit of this series already and then deal with the problem parts. sure, it at least some of those patches get merged, then it's less crap for me to rebase every now and again. This is the third time I rebase the series after a long hiatus and it always comes out to the same result - let's wait some more. Nope, it's always been this series causes PM regressions you just said that we haven't been in any position to really test this, so can it be that the status has always been this series causes PM regressions. We couldn't test that before, right ? and few other minor comments. And we have not been in any position to really test that until with v3.16-rc4. And then you always run out of time and nobody else does anything :) sure, I have other stuff to do as well. -- balbi signature.asc Description: Digital signature
Re: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain
* Felipe Balbi ba...@ti.com [140729 07:18]: Hi, On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140728 14:19]: now that we don't need to support legacy board-files, we can completely switch over to a linear irq domain and make use of irq_alloc_domain_generic_chips() to allocate all generic irq chips for us. This patch seems to somehow break off-idle for omap3 where it no longer wakes up. Sure your bisection is correct ? This patch just switches from legacy irq domain to linear irq domain. Yes, I tried it a few times. Just enabling retention idle hangs too with this patch. Maybe it's omap3_prcm_irq_setup that relies on 11 + OMAP_INTC_START? There may be other such issues remaining too but most should be already fixed up. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 30/35] irqchip: add irq-omap-intc.h header
* Felipe Balbi ba...@ti.com [140729 08:22]: On Tue, Jul 29, 2014 at 08:06:55AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 07:13]: This is the third time I rebase the series after a long hiatus and it always comes out to the same result - let's wait some more. Nope, it's always been this series causes PM regressions you just said that we haven't been in any position to really test this, so can it be that the status has always been this series causes PM regressions. We couldn't test that before, right ? It's been working for legacy booting for years with the mainline kernel, but not for device tree based booting until with v3.16-rc4. I believe I tested your earlier series with my pending DT patches though. and few other minor comments. And we have not been in any position to really test that until with v3.16-rc4. And then you always run out of time and nobody else does anything :) sure, I have other stuff to do as well. Right :) I and others can provide some help here, but it's the mr. patch author that needs to follow up on this series too :p Regards, Tony -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: use IORESOURCE_REG resource type for non-translatable addresses in DT
On Tue, Jul 29, 2014 at 9:06 AM, Stanimir Varbanov svarba...@mm-sol.com wrote:
Arnd, thanks for the comments.
On 07/29/2014 03:00 PM, Arnd Bergmann wrote:
On Tuesday 29 July 2014 14:42:31 Stanimir Varbanov wrote:
taddr = of_translate_address(dev, addrp);
- if (taddr == OF_BAD_ADDR)
- return -EINVAL;
+ /*
+* if the address is non-translatable to cpu physical address
+* fallback to a IORESOURCE_REG resource.
+*/
+ if (taddr == OF_BAD_ADDR) {
+ memset(r, 0, sizeof(*r));
+ taddr = of_read_number(addrp, 1);
+ if (taddr == OF_BAD_ADDR)
+ return -EINVAL;
+ r-start = taddr;
+ r-end = taddr + size - 1;
+ r-flags = IORESOURCE_REG;
+ r-name = name ? name : dev-full_name;
+ return 0;
+ }
+
I don't think that everything returning OF_BAD_ADDR makes sense
to turn into IORESOURCE_REG. It could be an e.g. invalid DT
representation, a node with #size-cells=0, or it could be
something that gets translated one or more nodes up in the
tree before it reaches a bus without a ranges property.
Also, you should not rely on #address-cells being hardcoded
to 1 above.
This was just an example. Of course it has many issues and probaly it is
wrong:) The main goal was to understand does IORESOURCE_REG resource
type and parsing the *reg* properties for non-translatable addresses are
feasible. And also does it acceptable by community and OF platform
maintainers.
I guess the question I have is what is the advantage of making this a
resource? You can't really pass it to other functions.
We're moving in the opposite direction for IRQs as now
platform_get_irq translates the IRQ directly rather than using the
resource (but the resource is still there just to avoid potentially
breaking things for now).
How about modifying of_get_address() rather than
__of_address_to_resource() instead? You could introduce
a new of_bus entry for each bus you expect to return
an IORESOURCE_REG, or you could change of_bus_default_get_flags
to return IORESOURCE_REG if the parent node has no ranges property
and is not the root node.
IMO the clearer solution is to introduce a new of_bus bus. In that case
one possible problem will be how to distinguish the non-translatable and
the other buses. Also the *device_type* property is deprecated for non
PCI devices.
You would have to look for the presence or absence of ranges property.
Rob
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: dts: exynos5250: Fold common ChromeOS parts into Snow
Andreas,
On Tue, Jul 29, 2014 at 6:00 AM, Andreas Färber afaer...@suse.de wrote:
Hi Javier and Doug,
Am 25.07.2014 19:02, schrieb Javier Martinez Canillas:
On Fri, Jul 25, 2014 at 6:43 PM, Doug Anderson diand...@chromium.org wrote:
On Fri, Jul 25, 2014 at 9:35 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
Hello Andreas,
On Fri, Jul 18, 2014 at 7:20 PM, Andreas Färber afaer...@suse.de wrote:
+ memory {
+ reg = 0x4000 0x8000;
+ };
+
+ chosen {
+ };
+
Is there a reason for an empty chosen node? Same for the Spring DTS.
I know that the bootloader (U-Boot) fills this in. I'd have to double
check how the bootloader handles the node not being there to begin
with.
Yes, U-Boot fills this but if the node does not exist in the FDT, it
creates one. Take a look at fdt_chosen() in common/fdt_support.c [0].
So I think it's better to just remove it since is empty.
Hm, in different context it was stated that device trees shouldn't rely
on bootloader behavior (for a /memory node on Zynq we ended up
specifying the size cell with the real value despite U-Boot overriding
it to a lesser value).
Can we instead settle on filling this node with defaults? :)
bootargs = console=tty1; would be my choice for Spring. Would that be
applicable for Snow as well?
Personally I think that there's not a lot of use for including
bootargs. Every single person will need different bootargs since
everyone will have a different boot source (eMMC partitioin 0, eMMC
partition3, SD card, USB, etc). You have to rely on the bootloader
for _something_.
Not sure how to specify that via linux,stdout-path property.
I believe this would be a follow-up patch either way.
Right
Since there's at least two series out there trying to fiddle with
-cros-common.dtsi, including one that drops the slot sub-node of the MMC
and one that adds CPU power supply, it would be nice if we can get the
-cros-common parts sorted out and applied. Can you ack/review 1-2?
Should I squash them in a v3?
Yeah, it will be a fight to see who gets landed first... :-P
I was thinking you were going to spin the patches and I'd do another
batch of review, but I think I can mark the first two as Reveiwed-by
if it's helpful to you. Let me do one more double-check when I get to
my desk.
-Doug
--
To unsubscribe from this list: send the line 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 29/35] arm: omap: intc: switch over to linear irq domain
On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 07:18]: Hi, On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140728 14:19]: now that we don't need to support legacy board-files, we can completely switch over to a linear irq domain and make use of irq_alloc_domain_generic_chips() to allocate all generic irq chips for us. This patch seems to somehow break off-idle for omap3 where it no longer wakes up. Sure your bisection is correct ? This patch just switches from legacy irq domain to linear irq domain. Yes, I tried it a few times. Just enabling retention idle hangs too with this patch. Maybe it's omap3_prcm_irq_setup that relies on 11 + OMAP_INTC_START? There may be other such issues lol. OMAP4 has the same nonsense. -- balbi signature.asc Description: Digital signature
Re: [PATCH 13/35] arm: omap: irq: call set_handle_irq() from intc_of_init
On Tue, Jul 29, 2014 at 04:20:20AM +0200, Sebastian Reichel wrote: Hi, On Mon, Jul 28, 2014 at 04:16:01PM -0500, Felipe Balbi wrote: this will let us drop .handle_irq and .init_irq fields from our generic machine_descs. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap2/irq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c index e6997c5..e452411 100644 --- a/arch/arm/mach-omap2/irq.c +++ b/arch/arm/mach-omap2/irq.c @@ -314,6 +314,8 @@ static int __init intc_of_init(struct device_node *node, omap_init_irq(res.start, nr_irq, of_node_get(node)); + set_handle_irq(omap2_intc_handle_irq); + return 0; } if you respin the patchset you may want to call omap_intc_handle_irq directly. It makes the review of the patchset less confusing. (I was wondering why omap3 can call omap2_intc_handle_irq until I noticed, that your previous changes made both functions simple wrapper functions for omap_intc_handle_irq) this is done later for a reason. At this point, omap_intc_handle_irq() still misses proper annotations for asmlinkage and __exception_irq_entry. -- balbi signature.asc Description: Digital signature
Re: [PATCH 13/35] arm: omap: irq: call set_handle_irq() from intc_of_init
Hi,
On Tue, Jul 29, 2014 at 10:36:49AM -0500, Felipe Balbi wrote:
On Tue, Jul 29, 2014 at 04:20:20AM +0200, Sebastian Reichel wrote:
Hi,
On Mon, Jul 28, 2014 at 04:16:01PM -0500, Felipe Balbi wrote:
this will let us drop .handle_irq and .init_irq fields
from our generic machine_descs.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/irq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index e6997c5..e452411 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -314,6 +314,8 @@ static int __init intc_of_init(struct device_node
*node,
omap_init_irq(res.start, nr_irq, of_node_get(node));
+ set_handle_irq(omap2_intc_handle_irq);
+
return 0;
}
if you respin the patchset you may want to call omap_intc_handle_irq
directly. It makes the review of the patchset less confusing.
(I was wondering why omap3 can call omap2_intc_handle_irq until I
noticed, that your previous changes made both functions simple
wrapper functions for omap_intc_handle_irq)
this is done later for a reason. At this point, omap_intc_handle_irq()
still misses proper annotations for asmlinkage and
__exception_irq_entry.
I guess that could be solved by moving the annotations to
omap_intc_handle_irq and just keeping omap{23}_intc_handle_irq as a
#define. Probably not worth the extra work, though.
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCH v2 2/4] ARM: dts: exynos5250: cypress,cyapa trackpad is Snow only
Andreas, On Fri, Jul 18, 2014 at 10:20 AM, Andreas Färber afaer...@suse.de wrote: Move it from exynos5250-cros-common.dtsi to exynos5250-snow.dts. Spring does not need it, it uses an Atmel maXTouch instead. Signed-off-by: Andreas Färber afaer...@suse.de --- v2: New (Doug Anderson) arch/arm/boot/dts/exynos5250-cros-common.dtsi | 8 arch/arm/boot/dts/exynos5250-snow.dts | 10 ++ 2 files changed, 10 insertions(+), 8 deletions(-) Reviewed-by: Doug Anderson diand...@chromium.org Kukjin could apply this now if he wanted to avoid future conflicts. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: dts: exynos5250: max77686 is Snow only
Andreas, On Fri, Jul 18, 2014 at 10:20 AM, Andreas Färber afaer...@suse.de wrote: Move it from exynos5250-cros-common.dtsi to exynos5250-snow.dts. Spring does not need it, it uses an s5m8767 instead. Signed-off-by: Andreas Färber afaer...@suse.de --- v2: New (Doug Anderson) arch/arm/boot/dts/exynos5250-cros-common.dtsi | 151 - arch/arm/boot/dts/exynos5250-snow.dts | 155 ++ 2 files changed, 155 insertions(+), 151 deletions(-) Personally I would have squashed patches 1-3, but I don't have a problem with it being broken up and it does mean that the mondo patch is smaller, so... Reviewed-by: Doug Anderson diand...@chromium.org Kukjin could apply this now if he wanted to avoid future conflicts. -Doug -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/5] Get voltage from parent if not available on child
Hello,
The motivation for this series is that some regulators are
really just switches that provide as output voltage what is
supplied to them as input voltage. These components can be
only switched on and off so the drivers usually implements
a subset of the possible regulator operations. That is only
.enable, .disable and .is_enabled but no .{get,list}_voltage
But there is code that assume all regulators can provide
their output voltage so if one of these load switches are
used as an input supply a call to regulator_get_voltage() or
regulator_list_voltage() will fail.
As an example in [0] mmc_regulator_get_supply() is used to
obtain the vmmc supply but on Peach Pit and Pi boards this
is tps65090 fet4 which is a load switch so the call to
mmc_regulator_get_ocrmask() fails since it tries to obtain
the regulator voltage count and list.
mmc_regulator_set_ocr() function fails as well since it calls
regulator_get_voltage() which the driver does not implement.
Since this seems to be a general issue we can pass through
and query the parent supply voltage when a child regulator
does not implement the handlers to obtain its output voltage.
The series have been tested on a Exynos 5420 Peach Pit board
and is composed of the following patches:
Javier Martinez Canillas (5):
regulator: core: Get voltage from parent if not available
regulator: core: Allow to get voltage count and list from parent
regulator: core: Only apply constraints if available on list voltage
regulator: tps65090: Set voltage for fixed regulators
ARM: dts: Improve Peach Pit and Pi power scheme model
arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 +--
arch/arm/boot/dts/exynos5800-peach-pi.dts | 12 +--
drivers/regulator/core.c | 31 ---
drivers/regulator/tps65090-regulator.c | 34 ++
4 files changed, 56 insertions(+), 33 deletions(-)
Patch 1 adds support to get the voltage of the parent supply
while patch 2 does the same for selector count and selector.
Patch 3 only applies the constraints when querying a selector
if there were constraints defined for this regulator. Otherwise
the constraints of the parent supply will be applied when
calling regulator_list_voltage() for the parent supply. Patch
4 adds information about the voltage output for the fixed
regulators found on the tps65090 since these are parent supply
of the fets load switches. Finally patch 5 models the real
relation between regulators in the Peach Pit and Pi boards
instead of the simplistic model that is implemented now.
This last patch should not be merged with the series but since
is a RFC I included so it can be tested on Peach boards and
to provide the complete picture.
Best regards,
Javier
[0]: https://patchwork.kernel.org/patch/4401231/
[1]: http://lxr.free-electrons.com/source/drivers/mmc/core/core.c#L1253
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 5/5] ARM: dts: Improve Peach Pit and Pi power scheme model
The DeviceTree files for the Peach Pit and Pi machines have a simplistic model of the connections between the different regulators since not all the tps65090 regulators get their input supply voltage from the VDC. DCDC1-3, LD0-1 and fet7 parent supply is indded VDC but the fet1-6 get their input supply from the DCDC1 and DCDC2 output voltage rails. This information has to be present in the DTS since fets are switches that don't provide an output voltage so when this is needed, the parent input supply voltage is queried. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 12 ++-- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts index 7656a42..acc2936 100644 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts @@ -367,12 +367,12 @@ vsys2-supply = vbat; vsys3-supply = vbat; infet1-supply = vbat; - infet2-supply = vbat; - infet3-supply = vbat; - infet4-supply = vbat; - infet5-supply = vbat; - infet6-supply = vbat; - infet7-supply = vbat; + infet2-supply = tps65090_dcdc1; + infet3-supply = tps65090_dcdc2; + infet4-supply = tps65090_dcdc2; + infet5-supply = tps65090_dcdc2; + infet6-supply = tps65090_dcdc2; + infet7-supply = tps65090_dcdc1; vsys-l1-supply = vbat; vsys-l2-supply = vbat; diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts index 5f3e54f..6b83b98 100644 --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts @@ -365,12 +365,12 @@ vsys2-supply = vbat; vsys3-supply = vbat; infet1-supply = vbat; - infet2-supply = vbat; - infet3-supply = vbat; - infet4-supply = vbat; - infet5-supply = vbat; - infet6-supply = vbat; - infet7-supply = vbat; + infet2-supply = tps65090_dcdc1; + infet3-supply = tps65090_dcdc2; + infet4-supply = tps65090_dcdc2; + infet5-supply = tps65090_dcdc2; + infet6-supply = tps65090_dcdc2; + infet7-supply = tps65090_dcdc1; vsys-l1-supply = vbat; vsys-l2-supply = vbat; -- 2.0.0.rc2 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/5] regulator: tps65090: Set voltage for fixed regulators
According to the tps65090 data manual [0], the DCDC1 and DCDC2
step-down converters and the LDO's have a fixed output voltage.
Add this information to the driver since these fixed regulators
be used as input supply for load switches which don't provide
an output voltage and their parent supply voltage is used.
[0]: http://www.ti.com/lit/gpn/tps65090
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/regulator/tps65090-regulator.c | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 2064b3f..919f5ce 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -192,12 +192,14 @@ static struct regulator_ops tps65090_fet_control_ops = {
static struct regulator_ops tps65090_ldo_ops = {
};
-#define tps65090_REG_DESC(_id, _sname, _en_reg, _en_bits, _ops)\
+#define tps65090_REG_DESC(_id, _sname, _en_reg, _en_bits, _nvolt, _volt, _ops)
\
{ \
.name = TPS65090_RAILS#_id, \
.supply_name = _sname, \
.id = TPS65090_REGULATOR_##_id, \
+ .n_voltages = _nvolt, \
.ops = _ops, \
+ .fixed_uV = _volt, \
.enable_reg = _en_reg, \
.enable_val = _en_bits, \
.enable_mask = _en_bits,\
@@ -205,39 +207,45 @@ static struct regulator_ops tps65090_ldo_ops = {
.owner = THIS_MODULE, \
}
+#define tps65090_REG_FIX(_id, _sname, en_reg, _en_bits, _volt, _ops) \
+ tps65090_REG_DESC(_id, _sname, en_reg, _en_bits, 1, _volt, _ops)
+
+#define tps65090_REG_VAR(_id, _sname, en_reg, _en_bits, _ops) \
+ tps65090_REG_DESC(_id, _sname, en_reg, _en_bits, 0, 0, _ops)
+
static struct regulator_desc tps65090_regulator_desc[] = {
- tps65090_REG_DESC(DCDC1, vsys1, 0x0C, BIT(CTRL_EN_BIT),
+ tps65090_REG_FIX(DCDC1, vsys1, 0x0C, BIT(CTRL_EN_BIT), 500,
tps65090_reg_control_ops),
- tps65090_REG_DESC(DCDC2, vsys2, 0x0D, BIT(CTRL_EN_BIT),
+ tps65090_REG_FIX(DCDC2, vsys2, 0x0D, BIT(CTRL_EN_BIT), 330,
tps65090_reg_control_ops),
- tps65090_REG_DESC(DCDC3, vsys3, 0x0E, BIT(CTRL_EN_BIT),
+ tps65090_REG_VAR(DCDC3, vsys3, 0x0E, BIT(CTRL_EN_BIT),
tps65090_reg_control_ops),
- tps65090_REG_DESC(FET1, infet1, 0x0F,
+ tps65090_REG_VAR(FET1, infet1, 0x0F,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(FET2, infet2, 0x10,
+ tps65090_REG_VAR(FET2, infet2, 0x10,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(FET3, infet3, 0x11,
+ tps65090_REG_VAR(FET3, infet3, 0x11,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(FET4, infet4, 0x12,
+ tps65090_REG_VAR(FET4, infet4, 0x12,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(FET5, infet5, 0x13,
+ tps65090_REG_VAR(FET5, infet5, 0x13,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(FET6, infet6, 0x14,
+ tps65090_REG_VAR(FET6, infet6, 0x14,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(FET7, infet7, 0x15,
+ tps65090_REG_VAR(FET7, infet7, 0x15,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(LDO1, vsys-l1, 0, 0,
+ tps65090_REG_FIX(LDO1, vsys-l1, 0, 0, 500,
tps65090_ldo_ops),
- tps65090_REG_DESC(LDO2, vsys-l2, 0, 0,
+ tps65090_REG_FIX(LDO2, vsys-l2, 0, 0, 330,
tps65090_ldo_ops),
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/5] regulator: core: Only apply constraints if available on list voltage
If a selector can't be used on a platform due to voltage constraints,
regulator_list_voltage() returns 0. Doing this unconditionally made
sense since constraints were set in machine_constraints_voltage() at
regulator registration time.
But for load switches that don't define a voltage output, the parent
supply voltage is used so the constraints should only be applied if
they were defined for the child regulators.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/regulator/core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index a3c3785..7472535 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2228,9 +2228,11 @@ int regulator_list_voltage(struct regulator *regulator,
unsigned selector)
}
if (ret 0) {
- if (ret rdev-constraints-min_uV)
+ if (rdev-constraints-min_uV
+ ret rdev-constraints-min_uV)
ret = 0;
- else if (ret rdev-constraints-max_uV)
+ else if (rdev-constraints-max_uV
+ret rdev-constraints-max_uV)
ret = 0;
}
--
2.0.0.rc2
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/5] regulator: core: Allow to get voltage count and list from parent
Load switches are modeled as regulators but they just provide
the voltage of their parent input supply. So, the drivers for
these switches usually neither provide a .list_voltage handler
not set a .n_voltages count. But there is code in the kernel
that assumes that all regulators should be able to provide this
information (e.g: cpufreq and mmc subsystems).
If the voltage count and list are not available for a regulator
and it has a parent input supply, then use the parent values.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/regulator/core.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 089cea8..a3c3785 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2186,7 +2186,13 @@ int regulator_count_voltages(struct regulator *regulator)
{
struct regulator_dev*rdev = regulator-rdev;
- return rdev-desc-n_voltages ? : -EINVAL;
+ if (rdev-desc-n_voltages)
+ return rdev-desc-n_voltages;
+
+ if (!rdev-supply)
+ return -EINVAL;
+
+ return regulator_count_voltages(rdev-supply);
}
EXPORT_SYMBOL_GPL(regulator_count_voltages);
@@ -2209,12 +2215,17 @@ int regulator_list_voltage(struct regulator *regulator,
unsigned selector)
if (rdev-desc-fixed_uV rdev-desc-n_voltages == 1 !selector)
return rdev-desc-fixed_uV;
- if (!ops-list_voltage || selector = rdev-desc-n_voltages)
+ if (ops-list_voltage) {
+ if (selector = rdev-desc-n_voltages)
+ return -EINVAL;
+ mutex_lock(rdev-mutex);
+ ret = ops-list_voltage(rdev, selector);
+ mutex_unlock(rdev-mutex);
+ } else if (rdev-supply) {
+ ret = regulator_list_voltage(rdev-supply, selector);
+ } else {
return -EINVAL;
-
- mutex_lock(rdev-mutex);
- ret = ops-list_voltage(rdev, selector);
- mutex_unlock(rdev-mutex);
+ }
if (ret 0) {
if (ret rdev-constraints-min_uV)
--
2.0.0.rc2
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/5] regulator: core: Get voltage from parent if not available
Load switches are modeled as regulators but they just provide
the voltage of their parent input supply. So the drivers for
these switches usually don't provide a .get_voltage function
handler but there is code in the kernel that assumes that all
regulators should be able to provide its current voltage rail.
So, if the output voltage for a regulator is not available and
it has a parent supply, then pass the voltage of its parent.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/regulator/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 69c9c08..089cea8 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2695,6 +2695,8 @@ static int _regulator_get_voltage(struct regulator_dev
*rdev)
ret = rdev-desc-ops-list_voltage(rdev, 0);
} else if (rdev-desc-fixed_uV (rdev-desc-n_voltages == 1)) {
ret = rdev-desc-fixed_uV;
+ } else if (rdev-supply) {
+ ret = regulator_get_voltage(rdev-supply);
} else {
return -EINVAL;
}
--
2.0.0.rc2
--
To unsubscribe from this list: send the line 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 29/35] arm: omap: intc: switch over to linear irq domain
Hi,
On Tue, Jul 29, 2014 at 10:40:57AM -0500, Felipe Balbi wrote:
On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [140729 07:18]:
Hi,
On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [140728 14:19]:
now that we don't need to support legacy board-files,
we can completely switch over to a linear irq domain
and make use of irq_alloc_domain_generic_chips() to
allocate all generic irq chips for us.
This patch seems to somehow break off-idle for omap3
where it no longer wakes up.
Sure your bisection is correct ? This patch just switches from legacy
irq domain to linear irq domain.
Yes, I tried it a few times. Just enabling
retention idle hangs too with this patch.
Maybe it's omap3_prcm_irq_setup that relies on
11 + OMAP_INTC_START? There may be other such issues
lol.
OMAP4 has the same nonsense.
made me think why (if) OMAP4 works with that same setup. Does wake from
OFF work with OMAP4 ?
Anyway, here's a quick little hack to check if that's the reason for the
regression:
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index ff953c9..c234b98 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -97,6 +97,7 @@
prm: prm@48306000 {
compatible = ti,omap3-prm;
reg = 0x48306000 0x4000;
+ interrupts = 11;
prm_clocks: clocks {
#address-cells = 1;
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 25e8b82..3d11377 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -242,6 +242,11 @@ void omap_prcm_irq_complete(void)
prcm_irq_setup-restore_irqen(prcm_irq_setup-saved_mask);
}
+static struct of_device_id tmp[] = {
+ { .compatible = ti,omap3-prm },
+ { }
+};
+
/**
* omap_prcm_register_chain_handler - initializes the prcm chained interrupt
* handler based on provided parameters
@@ -254,17 +259,24 @@ void omap_prcm_irq_complete(void)
*/
int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
{
+ struct device_node *node;
int nr_regs;
u32 mask[OMAP_PRCM_MAX_NR_PENDING_REG];
int offset, i;
+ int irq;
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
if (!irq_setup)
return -EINVAL;
+ irq = irq_setup-irq;
nr_regs = irq_setup-nr_regs;
+ node = of_find_matching_node(NULL, tmp);
+ if (node)
+ irq = of_irq_get(node, 0);
+
if (prcm_irq_setup) {
pr_err(PRCM: already initialized; won't reinitialize\n);
return -EINVAL;
@@ -298,7 +310,7 @@ int omap_prcm_register_chain_handler(struct
omap_prcm_irq_setup *irq_setup)
1 (offset 0x1f);
}
- irq_set_chained_handler(irq_setup-irq, omap_prcm_irq_handler);
+ irq_set_chained_handler(irq, omap_prcm_irq_handler);
irq_setup-base_irq = irq_alloc_descs(-1, 0, irq_setup-nr_regs * 32,
0);
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2] mmc: dw_mmc: add support for RK3288
Addy,
On Mon, Jul 28, 2014 at 9:52 PM, Doug Anderson diand...@chromium.org wrote:
Addy,
On Wed, Jul 9, 2014 at 8:31 PM, Addy Ke addy...@rock-chips.com wrote:
This patch focuses on clock setting for RK3288 mmc controller.
In RK3288 mmc controller, CLKDIV register can only be set 0 or 1,
and if DDR 8bit mode, CLKDIV register must be set 1.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
changes since v1:
- dw_mci_rk3288_setup_clock: do not call clk_get_rate(), just use the
host-bus_hz which is already called by dw_mmc.c, suggested by Jaehoon
Chung
.../devicetree/bindings/mmc/rockchip-dw-mshc.txt | 4 +-
drivers/mmc/host/dw_mmc-pltfm.c| 50
+-
2 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
index c559f3f..e3f95cd 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
@@ -10,7 +10,9 @@ extensions to the Synopsys Designware Mobile Storage Host
Controller.
Required Properties:
* compatible: should be
- - rockchip,rk2928-dw-mshc: for Rockchip RK2928 and following
+ - rockchip,rk2928-dw-mshc: for Rockchip RK2928 and following,
+ before RK3288
+ - rockchip,rk3288-dw-mshc: for Rockchip RK3288
Example:
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
b/drivers/mmc/host/dw_mmc-pltfm.c
index d4a47a9..809c28b 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -21,17 +21,61 @@
#include linux/mmc/mmc.h
#include linux/mmc/dw_mmc.h
#include linux/of.h
+#include linux/clk.h
#include dw_mmc.h
#include dw_mmc-pltfm.h
+#define RK3288_CLKGEN_DIV 2
Yup, this matches what I see in the TRM. It will always divide by 2
to allow for 4 phases (picking the phases not supported yet). Default
phase looks to be 180 degrees which is why we've (currently) got
USE_HOLD_REG hardcoded. :)
+
static void dw_mci_pltfm_prepare_command(struct dw_mci *host, u32 *cmdr)
{
*cmdr |= SDMMC_CMD_USE_HOLD_REG;
}
-static const struct dw_mci_drv_data rockchip_drv_data = {
+static int dw_mci_rk3288_setup_clock(struct dw_mci *host)
+{
+ host-bus_hz /= RK3288_CLKGEN_DIV;
+
+ return 0;
+}
+
+static void dw_mci_rk3288_set_ios(struct dw_mci *host, struct mmc_ios *ios)
+{
+ int ret;
+ unsigned int cclkin;
+
+ /*
+* cclkin: source clock of mmc controller.
+* bus_hz: card interface clock generated by CLKGEN.
+* bus_hz = cclkin / RK3288_CLKGEN_DIV;
+* ios-clock = (div == 0) ? bus_hz : (bus_hz / (2 * div))
+*
+* Note: div can only be 0 or 1
+* if DDR50 8bit mode, div must be set 1
Makes sense. So this function is essentially reversing the logic in
dw_mmc and making sure that we'll get the right DIV (0 or 1) in
dw_mci_setup_bus().
+*/
+ if ((ios-bus_width == MMC_BUS_WIDTH_8)
+ (ios-timing == MMC_TIMING_UHS_DDR50 ||
Probably don't need UHS_DDR50 since (I think) you can't have an 8-bit
SD card--only MMC, right? ...but it doesn't hurt.
+ios-timing == MMC_TIMING_MMC_DDR52))
+ cclkin = 2 * ios-clock * RK3288_CLKGEN_DIV;
+ else
+ cclkin = ios-clock * RK3288_CLKGEN_DIV;
+
+ ret = clk_set_rate(host-ciu_clk, cclkin);
+ if (ret)
+ dev_warn(host-dev, failed to set rate %uHz\n, ios-clock);
+
+ host-bus_hz = clk_get_rate(host-ciu_clk) / RK3288_CLKGEN_DIV;
+}
+
+static const struct dw_mci_drv_data rk2928_drv_data = {
+ .prepare_command= dw_mci_pltfm_prepare_command,
+};
+
+static const struct dw_mci_drv_data rk3288_drv_data = {
.prepare_command= dw_mci_pltfm_prepare_command,
+ .set_ios= dw_mci_rk3288_set_ios,
+ .setup_clock= dw_mci_rk3288_setup_clock,
};
static const struct dw_mci_drv_data socfpga_drv_data = {
@@ -95,7 +139,9 @@ EXPORT_SYMBOL_GPL(dw_mci_pltfm_pmops);
static const struct of_device_id dw_mci_pltfm_match[] = {
{ .compatible = snps,dw-mshc, },
{ .compatible = rockchip,rk2928-dw-mshc,
- .data = rockchip_drv_data },
+ .data = rk2928_drv_data },
+ { .compatible = rockchip,rk3288-dw-mshc,
+ .data = rk3288_drv_data },
{ .compatible = altr,socfpga-dw-mshc,
.data = socfpga_drv_data },
{},
Reviewed-by: Doug Anderson diand...@chromium.org
Tested-by: Doug Anderson diand...@chromium.org
It turns out that I spoke too soon. I realized that in my testing I
didn't have DDR mode enabled for my eMMC card. When I did that then
your patch didn't work.
The problem is that dw_mci_setup_bus() doesn't realize that you've
[PATCH] ARM: dt: sun7i: Add Banana Pi board
The Banana Pi is an A20 based development board using Raspberry Pi compatible
IO headers. It comes with 1 GB RAM, 1 Gb ethernet, 2x USB host, sata, hdmi
and stereo audio out + various expenansion headers:
http://www.bananapi.org/
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 183 +++
2 files changed, 184 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-bananapi.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bdbc84a..440e037 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -379,6 +379,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31-hummingbird.dtb \
sun6i-a31-m9.dtb
dtb-$(CONFIG_MACH_SUN7I) += \
+ sun7i-a20-bananapi.dtb \
sun7i-a20-cubieboard2.dtb \
sun7i-a20-cubietruck.dtb \
sun7i-a20-i12-tvbox.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
new file mode 100644
index 000..0332b82
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -0,0 +1,183 @@
+/*
+ * Copyright 2014 Hans de Goede hdego...@redhat.com
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ sun7i-a20.dtsi
+/include/ sunxi-common-regulators.dtsi
+
+/ {
+ model = LeMaker Banana Pi;
+ compatible = lemaker,bananapi, allwinner,sun7i-a20;
+
+ soc@01c0 {
+ spi0: spi@01c05000 {
+ pinctrl-names = default;
+ pinctrl-0 = spi0_pins_a;
+ status = okay;
+ };
+
+ mmc0: mmc@01c0f000 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc0_pins_a, mmc0_cd_pin_bananapi;
+ vmmc-supply = reg_vcc3v3;
+ bus-width = 4;
+ cd-gpios = pio 7 10 0; /* PH10 */
+ cd-inverted;
+ status = okay;
+ };
+
+ usbphy: phy@01c13400 {
+ usb1_vbus-supply = reg_usb1_vbus;
+ usb2_vbus-supply = reg_usb2_vbus;
+ status = okay;
+ };
+
+ ehci0: usb@01c14000 {
+ status = okay;
+ };
+
+ ohci0: usb@01c14400 {
+ status = okay;
+ };
+
+ ahci: sata@01c18000 {
+ status = okay;
+ };
+
+ ehci1: usb@01c1c000 {
+ status = okay;
+ };
+
+ ohci1: usb@01c1c400 {
+ status = okay;
+ };
+
+ pinctrl@01c20800 {
+ uart3_pins_bananapi: uart3_pin@0 {
+ allwinner,pins = PH0, PH1;
+ allwinner,function = uart3;
+ allwinner,drive = 0;
+ allwinner,pull = 0;
+ };
+
+ mmc0_cd_pin_bananapi: mmc0_cd_pin@0 {
+ allwinner,pins = PH10;
+ allwinner,function = gpio_in;
+ allwinner,drive = 0;
+ allwinner,pull = 1;
+ };
+
+ gmac_power_pin_bananapi: gmac_power_pin@0 {
+ allwinner,pins = PH23;
+ allwinner,function = gpio_out;
+ allwinner,drive = 0;
+ allwinner,pull = 0;
+ };
+
+ led_pins_bananapi: led_pins@0 {
+ allwinner,pins = PH24;
+ allwinner,function = gpio_out;
+ allwinner,drive = 0;
+ allwinner,pull = 0;
+ };
+ };
+
+ ir0: ir@01c21800 {
+ pinctrl-names = default;
+ pinctrl-0 = ir0_pins_a;
+ status = okay;
+ };
+
+ uart0: serial@01c28000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins_a;
+ status = okay;
+ };
+
+ uart3: serial@01c28c00 {
+ pinctrl-names = default;
+ pinctrl-0 = uart3_pins_bananapi;
+ status = okay;
+ };
+
+ uart7: serial@01c29c00 {
+
Re: [RFC 3/5] regulator: core: Only apply constraints if available on list voltage
On Tue, Jul 29, 2014 at 06:28:57PM +0200, Javier Martinez Canillas wrote: If a selector can't be used on a platform due to voltage constraints, regulator_list_voltage() returns 0. Doing this unconditionally made sense since constraints were set in machine_constraints_voltage() at regulator registration time. But for load switches that don't define a voltage output, the parent supply voltage is used so the constraints should only be applied if they were defined for the child regulators. No, think about what you're doing here and why we're filtering out unsettable voltages - this causes problems for consumers on regulators that don't have any ability to vary voltages since they will now be able to list voltages that they can't select. I would also expect any regulator where the supplied devices are able to vary the voltage to explicitly provide a constraint even if the implementation is done in a parent regulator. There may be constraints on the child supply which aren't directly present on the parent supply and can be ignored if the child supply is turned off. signature.asc Description: Digital signature
Re: [RFC 5/5] ARM: dts: Improve Peach Pit and Pi power scheme model
On Tue, Jul 29, 2014 at 06:28:59PM +0200, Javier Martinez Canillas wrote: The DeviceTree files for the Peach Pit and Pi machines have a simplistic model of the connections between the different regulators since not all the tps65090 regulators get their input supply voltage from the VDC. DCDC1-3, LD0-1 and fet7 parent supply is indded VDC but the fet1-6 get their input supply from the DCDC1 and DCDC2 output voltage rails. Acked-by: Mark Brown broo...@linaro.org This *should* be independent of the rest of this series. signature.asc Description: Digital signature
Re: [RFC 4/5] regulator: tps65090: Set voltage for fixed regulators
On Tue, Jul 29, 2014 at 06:28:58PM +0200, Javier Martinez Canillas wrote: +#define tps65090_REG_VAR(_id, _sname, en_reg, _en_bits, _ops) \ + tps65090_REG_DESC(_id, _sname, en_reg, _en_bits, 0, 0, _ops) I'd expect this to describe a variable regulator when in fact it seems it describes a switch with no regulation. Better name please. signature.asc Description: Digital signature
Re: [PATCHv7 5/5] mmc: dw_mmc: replace disable-wp from slot's quirk to host's quirk
Jaehoon, On Sun, Jul 27, 2014 at 7:29 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Replaced the disable-wp into host's quirks. (Because the slot-node is removed at dt-file.) Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Tested-by: Sachin Kamat sachin.ka...@samsung.com Acked-by: Seungwon Jeon tgih@samsung.com --- drivers/mmc/host/dw_mmc.c | 12 +--- include/linux/mmc/dw_mmc.h |6 ++ 2 files changed, 7 insertions(+), 11 deletions(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 1ac227c..4a4f66f 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -997,7 +997,7 @@ static int dw_mci_get_ro(struct mmc_host *mmc) int gpio_ro = mmc_gpio_get_ro(mmc); /* Use platform get_ro function, else try on board write protect */ - if (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT) + if (slot-host-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT) It doesn't seem like it would be hard to include support for the old binding (and just print a warning). Then this could land ahead of the device tree changes. Generally I think we're supposed to keep support for old device trees if possible (except in extreme cases). -Doug -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/2] Add Freescale ASRC driver
On Tue, Jul 29, 2014 at 06:08:51PM +0800, Nicolin Chen wrote: This series of patches add Freescale ASRC module driver support along with the extra request in imx-sdma structure required by SDMA Device to Device script. Applied both, thanks. signature.asc Description: Digital signature
Re: [RFC 2/5] regulator: core: Allow to get voltage count and list from parent
On Tue, Jul 29, 2014 at 06:28:56PM +0200, Javier Martinez Canillas wrote: Load switches are modeled as regulators but they just provide the voltage of their parent input supply. So, the drivers for these switches usually neither provide a .list_voltage handler not set a .n_voltages count. But there is code in the kernel that assumes that all regulators should be able to provide this information (e.g: cpufreq and mmc subsystems). Applied, thanks. signature.asc Description: Digital signature
Re: [RFC 1/5] regulator: core: Get voltage from parent if not available
On Tue, Jul 29, 2014 at 06:28:55PM +0200, Javier Martinez Canillas wrote: Load switches are modeled as regulators but they just provide the voltage of their parent input supply. So the drivers for Applied, thanks. The term load switch is a bit unusual - they're usually just called switches (or sometimes FETs since that tends to be the implementation). signature.asc Description: Digital signature
[PATCH 2/4] ARM: rockchip: enable the AMBA bus
This is needed to access the pl330 dma controllers on Rockchip SoCs. Signed-off-by: Heiko Stuebner he...@sntech.de --- arch/arm/mach-rockchip/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index d168669..ac5803c 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -4,6 +4,7 @@ config ARCH_ROCKCHIP select PINCTRL_ROCKCHIP select ARCH_HAS_RESET_CONTROLLER select ARCH_REQUIRE_GPIOLIB + select ARM_AMBA select ARM_GIC select CACHE_L2X0 select HAVE_ARM_ARCH_TIMER -- 2.0.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 1/4] clk: rockchip: protect critical clocks from getting disabled
The clock-tree contains clocks that should never get disabled automatically.
One example are the base ACLKs, the base supplies for all peripherals.
Therefore add a structure similar to the sunxi clock-tree to protect these
special clocks from being disabled.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/clk/rockchip/clk-rk3188.c | 7 +++
drivers/clk/rockchip/clk-rk3288.c | 7 +++
drivers/clk/rockchip/clk.c| 13 +
drivers/clk/rockchip/clk.h| 1 +
4 files changed, 28 insertions(+)
diff --git a/drivers/clk/rockchip/clk-rk3188.c
b/drivers/clk/rockchip/clk-rk3188.c
index a83a6d8..5aef277 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -599,6 +599,11 @@ static struct rockchip_clk_branch rk3188_clk_branches[]
__initdata = {
GATE(ACLK_GPS, aclk_gps, aclk_peri, 0, RK2928_CLKGATE_CON(8), 13,
GFLAGS),
};
+static const char *rk3188_critical_clocks[] __initconst = {
+ aclk_cpu,
+ aclk_peri,
+};
+
static void __init rk3188_common_clk_init(struct device_node *np)
{
void __iomem *reg_base;
@@ -628,6 +633,8 @@ static void __init rk3188_common_clk_init(struct
device_node *np)
RK3188_GRF_SOC_STATUS);
rockchip_clk_register_branches(common_clk_branches,
ARRAY_SIZE(common_clk_branches));
+ rockchip_clk_protect_critical(rk3188_critical_clocks,
+ ARRAY_SIZE(rk3188_critical_clocks));
rockchip_register_softrst(np, 9, reg_base + RK2928_SOFTRST_CON(0),
ROCKCHIP_SOFTRST_HIWORD_MASK);
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 0d8c6c5..6c6f954 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -680,6 +680,11 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
GATE(0, pclk_isp_in, ext_isp, 0, RK3288_CLKGATE_CON(16), 3, GFLAGS),
};
+static const char *rk3288_critical_clocks[] __initconst = {
+ aclk_cpu,
+ aclk_peri,
+};
+
static void __init rk3288_clk_init(struct device_node *np)
{
void __iomem *reg_base;
@@ -710,6 +715,8 @@ static void __init rk3288_clk_init(struct device_node *np)
RK3288_GRF_SOC_STATUS);
rockchip_clk_register_branches(rk3288_clk_branches,
ARRAY_SIZE(rk3288_clk_branches));
+ rockchip_clk_protect_critical(rk3288_critical_clocks,
+ ARRAY_SIZE(rk3288_critical_clocks));
rockchip_register_softrst(np, 9, reg_base + RK3288_SOFTRST_CON(0),
ROCKCHIP_SOFTRST_HIWORD_MASK);
diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
index 278cf9d..9189f1b 100644
--- a/drivers/clk/rockchip/clk.c
+++ b/drivers/clk/rockchip/clk.c
@@ -242,3 +242,16 @@ void __init rockchip_clk_register_branches(
rockchip_clk_add_lookup(clk, list-id);
}
}
+
+void __init rockchip_clk_protect_critical(const char *clocks[], int nclocks)
+{
+ int i;
+
+ /* Protect the clocks that needs to stay on */
+ for (i = 0; i nclocks; i++) {
+ struct clk *clk = __clk_lookup(clocks[i]);
+
+ if (clk)
+ clk_prepare_enable(clk);
+ }
+}
diff --git a/drivers/clk/rockchip/clk.h b/drivers/clk/rockchip/clk.h
index 887cbde..2b0bca1 100644
--- a/drivers/clk/rockchip/clk.h
+++ b/drivers/clk/rockchip/clk.h
@@ -329,6 +329,7 @@ void rockchip_clk_register_branches(struct
rockchip_clk_branch *clk_list,
unsigned int nr_clk);
void rockchip_clk_register_plls(struct rockchip_pll_clock *pll_list,
unsigned int nr_pll, int grf_lock_offset);
+void rockchip_clk_protect_critical(const char *clocks[], int nclocks);
#define ROCKCHIP_SOFTRST_HIWORD_MASK BIT(0)
--
2.0.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 0/4] ARM: rockchip: add dma support
All Rockchip SoCs currently supported use pl330 dma controllers. The first patch introduces the concept of critical clocks, stolen from sunxi, as some core clocks shouldn't be disabled under normal circumstances. The patch is necessary, as the amba bus uses strict clock gating, which without this patch results in the core aclk getting disabled halting the system, before other components are able to probe and maybe claim their clocks. As the patches have no compile-time dependency on each other, the patchset could be split with the first patch going through the clock tree and the other three going through arm-soc. Heiko Stuebner (4): clk: rockchip: protect critical clocks from getting disabled ARM: rockchip: enable the AMBA bus ARM: dts: rockchip: add rk3288 dma controllers ARM: dts: rockchip: add rk3188 dma controllers arch/arm/boot/dts/rk3288.dtsi | 27 +++ arch/arm/boot/dts/rk3xxx.dtsi | 27 +++ arch/arm/mach-rockchip/Kconfig| 1 + drivers/clk/rockchip/clk-rk3188.c | 7 +++ drivers/clk/rockchip/clk-rk3288.c | 7 +++ drivers/clk/rockchip/clk.c| 13 + drivers/clk/rockchip/clk.h| 1 + 7 files changed, 83 insertions(+) -- 2.0.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 4/4] ARM: dts: rockchip: add rk3188 dma controllers
Add both the cpu and peripheral pl330 dma controllers present in rk3188 socs.
The first dma controller can change between secure and non-secure mode and is
left by the bootloader in secure mode, which gets added here.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/boot/dts/rk3xxx.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index c6f0561..a6c2860 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -28,6 +28,33 @@
i2c4 = i2c4;
};
+ amba {
+ compatible = arm,amba-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dmac1: dma@20018000 {
+ compatible = arm,pl330, arm,primecell;
+ reg = 0x20018000 0x4000;
+ interrupts = GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH;
+ #dma-cells = 1;
+ clocks = cru ACLK_DMA1;
+ clock-names = apb_pclk;
+ };
+
+ dmac2: dma@20078000 {
+ compatible = arm,pl330, arm,primecell;
+ reg = 0x20078000 0x4000;
+ interrupts = GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH;
+ #dma-cells = 1;
+ clocks = cru ACLK_DMA2;
+ clock-names = apb_pclk;
+ };
+ };
+
xin24m: oscillator {
compatible = fixed-clock;
clock-frequency = 2400;
--
2.0.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
