Re: [PATCH v3 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
On 12.02.2015 17:18, Alan Stern wrote: On Thu, 12 Feb 2015, Mathias Nyman wrote: On 25.01.2015 10:13, Sneeker Yeh wrote: This issue is defined by a three-way race at disconnect, between 1) Class driver interrupt endpoint resheduling attempts if the ISR gave an ep error event due to device detach (it would try 3 times) 2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread asynchronously 3) The hardware IP was configured in silicon with - DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1 - Synopsys IP version is 3.00a The IP will auto-suspend itself on device detach with some phy-specific interval after CSC is cleared by 2) If 2) and 3) complete before 1), the interrupts it expects will not be generated by the autosuspended IP, leading to a deadlock. Even later disconnection procedure would detect that corresponding urb is still in-progress and issue a ep stop command, auto-suspended IP still won't respond to that command. If the Synopsys IP provides a way to do it, it would be better to turn off the autosuspend feature entirely. Doesn't autosuspend violate the xHCI specification? So did I understand correctly that the class driver submits a new urb which is enqueued by xhci_urb_enqueue() before the hub thread notices the device is disconnected. Then hub thread clears CSC bit, controller suspends and the new urb is never given back? Doesn't the CSC bit and PORT_CONNECT bit show the device is disconnected when we enter xhci_enqueue_urb(), even it the hub thread doesn't know this yet? What if the device disconnects _after_ the new URB is enqueued? True, those URBs would be left hanging. So if possible, tweaking the Synopsis autosuspend feature would be nicer. If its not possible then I guess a quirk patch like this will do. -Mathias -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
On 25.01.2015 10:13, Sneeker Yeh wrote:
Oh, and one more thing:
+static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int dev_port_num)
+{
+ int max_ports;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ __le32 __iomem **port_array;
+ u32 status;
+
+ /* print debug info */
+ if (hcd-speed == HCD_USB3) {
+ max_ports = xhci-num_usb3_ports;
+ port_array = xhci-usb3_ports;
+ } else {
+ max_ports = xhci-num_usb2_ports;
+ port_array = xhci-usb2_ports;
+ }
+
+ if (dev_port_num max_ports) {
+ xhci_err(xhci, %s() port number invalid, __func__);
+ return;
+ }
+ status = readl(port_array[dev_port_num - 1]);
+
+ /* write 1 to clear */
+ if (!(status PORT_CONNECT) (status PORT_CSC))
+ writel(status PORT_CSC, port_array[0]);
We don't want to write back all the bits we read from the PORTSC register.
Use the xhci_put_state_to_neutral(status) helper function to mask out some RW1C
bits.
This in addition to writing to the correct PORTSC register as I previously
mentioned.
-Mathias
--
To unsubscribe from this list: send the line 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 08/14] pinctrl: Add pinctrl driver for STM32 MCUs
2015-02-12 21:37 GMT+01:00 Geert Uytterhoeven ge...@linux-m68k.org: On Thu, Feb 12, 2015 at 6:45 PM, Maxime Coquelin mcoquelin.st...@gmail.com wrote: --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -125,6 +125,15 @@ config PINCTRL_ST select PINCONF select GPIOLIB_IRQCHIP +config PINCTRL_STM32 + bool STMicroelectronics STM32 pinctrl driver + depends on OF depends on ARCH_STM32 || COMPILE_TEST Ok, I agree. It will be part of the v2. Thanks, Maxime -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] ARM: ARMv7M: Enlarge vector table to 256 entries
Hi Geert, 2015-02-12 21:34 GMT+01:00 Geert Uytterhoeven ge...@linux-m68k.org: On Thu, Feb 12, 2015 at 6:45 PM, Maxime Coquelin mcoquelin.st...@gmail.com wrote: From Cortex-M4 and M7 reference manuals, the nvic supports up to 240 interrupts. So the number of entries in vectors table is 256. This patch adds the missing entries, and change the alignement, so that vector_table remains naturally aligned. Shouldn't this depend on ARCH_STM32, or some other M4 or M7 specific Kconfig option, to avoid wasting the space on other CPUs? Actually, the STM32F429 has 90 interrupts, so it would need 106 entries in the vector table. The maximum of supported interrupts is not only for Cortex-M4 and M7, this is also true for Cortex-M3. I see two possibilities: 1 - We declare the vector table for the maximum supported number of IRQs, as this patch does. - Pro: it will be functionnal with all Cortex-M MCUs - Con: Waste of less than 1KB for memory 2 - We introduce a config flag that provides the number of interrupts - Pro: No more memory waste - Con: Need to declare a per MCU model config flag. Then, regarding the natural alignment, is there a way to ensure it depending on the value of a config flag? Or we should keep it at the maximum value possible? Any feedback will be appreciated, especially from Uwe who maintains the efm32 machine. Kind regards, Maxime -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] ARM: ARMv7M: Enlarge vector table to 256 entries
On Fri, Feb 13, 2015 at 09:42:46AM +0100, Maxime Coquelin wrote: Hi Geert, 2015-02-12 21:34 GMT+01:00 Geert Uytterhoeven ge...@linux-m68k.org: On Thu, Feb 12, 2015 at 6:45 PM, Maxime Coquelin mcoquelin.st...@gmail.com wrote: From Cortex-M4 and M7 reference manuals, the nvic supports up to 240 interrupts. So the number of entries in vectors table is 256. This patch adds the missing entries, and change the alignement, so that vector_table remains naturally aligned. Shouldn't this depend on ARCH_STM32, or some other M4 or M7 specific Kconfig option, to avoid wasting the space on other CPUs? Actually, the STM32F429 has 90 interrupts, so it would need 106 entries in the vector table. The maximum of supported interrupts is not only for Cortex-M4 and M7, this is also true for Cortex-M3. I see two possibilities: 1 - We declare the vector table for the maximum supported number of IRQs, as this patch does. - Pro: it will be functionnal with all Cortex-M MCUs - Con: Waste of less than 1KB for memory 2 - We introduce a config flag that provides the number of interrupts - Pro: No more memory waste - Con: Need to declare a per MCU model config flag. I'd vote for 2, something like: config CPUV7M_NUM_IRQ int default 90 if STM32F429 default 38 if EFM32GG default 240 then there is a working default and platforms being short on memory can configure as appropriate. (The only down side is that if we create multi-platfrom images at some time in the future either all or none of the supported platforms must provide a value here.) Then, regarding the natural alignment, is there a way to ensure it depending on the value of a config flag? The exact wording in ARMARMv7-M is: The Vector table must be naturally aligned to a power of two whose alignment value is greater than or equal to (Number of Exceptions supported x 4), with a minimum alignment of 128 bytes. Or we should keep it at the maximum value possible? So we need: .align x with x being max(7, ceil(log((CPUV7M_NUM_IRQ + 16) * 4, 2))). So the alignment needed is between 7 and 10. If the assembler supports an expression here I'd use that. But before adding strange hacks to generate the right value there better go for a static value like: /* The vector table must be naturally aligned */ #if CONFIG_CPUV7M_NUM_IRQ = 112 .align 9 /* log2((112 + 16) * 4) */ #else .align 10 #endif Further steps would be: CONFIG_CPUV7M_NUM_IRQ = 48 - .align 8 CONFIG_CPUV7M_NUM_IRQ = 16 - .align 7 Probably it's not worth to add the respective #ifdefs here. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] mmc: dw_mmc: fix bug that cause 'Timeout sending command'
On 2015/2/12 21:59, Alim Akhtar wrote:
On Thu, Feb 12, 2015 at 4:40 PM, Andrzej Hajda a.ha...@samsung.com wrote:
On 02/12/2015 03:28 AM, addy ke wrote:
Hi Andrzej and Alim
On 2015/2/12 07:20, Alim Akhtar wrote:
Hi Andrzej,
On Wed, Feb 11, 2015 at 5:28 PM, Andrzej Hajda a.ha...@samsung.com wrote:
Hi Alim,
On 02/11/2015 03:57 AM, Addy wrote:
On 2015/02/10 23:22, Alim Akhtar wrote:
Hi Addy,
On Mon, Feb 9, 2015 at 12:55 PM, Addy Ke addy...@rock-chips.com wrote:
Because of some uncertain factors, such as worse card or worse
hardware,
DAT[3:0](the data lines) may be pulled down by card, and mmc controller
will be in busy state. This should not happend when mmc controller
send command to update card clocks. If this happends, mci_send_cmd will
be failed and we will get 'Timeout sending command', and then system
will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4d2e3c2..b0b57e3 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -100,6 +100,7 @@ struct idmac_desc {
};
#endif /* CONFIG_MMC_DW_IDMAC */
+static int dw_mci_card_busy(struct mmc_host *mmc);
static bool dw_mci_reset(struct dw_mci *host);
static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
@@ -888,6 +889,31 @@ static void mci_send_cmd(struct dw_mci_slot
*slot, u32 cmd, u32 arg)
cmd, arg, cmd_status);
}
+static void dw_mci_wait_busy(struct dw_mci_slot *slot)
+{
+ struct dw_mci *host = slot-host;
+ unsigned long timeout = jiffies + msecs_to_jiffies(500);
+
Why 500 msec?
This timeout value is the same as mci_send_cmd:
static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg)
{
struct dw_mci *host = slot-host;
unsigned long timeout = jiffies + msecs_to_jiffies(500);
}
I have not clear that which is suitable.
Do you have any suggestion on it?
+ do {
+ if (!dw_mci_card_busy(slot-mmc))
+ return;
+ cpu_relax();
+ } while (time_before(jiffies, timeout));
+
+ dev_err(host-dev, Data busy (status %#x)\n,
+ mci_readl(slot-host, STATUS));
+
+ /*
+* Data busy, this should not happend when mmc controller send
command
+* to update card clocks in non-volt-switch state. If it
happends, we
+* should reset controller to avoid getting Timeout sending
command.
+*/
+ dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS);
+
Why you need to reset all blocks? may be CTRL_RESET is good enough here.
I have tested on rk3288, if only reset ctroller, data busy bit will not
be cleaned,and we will still get
Timeout sending command.
+ /* Fail to reset controller or still data busy, WARN_ON! */
+ WARN_ON(dw_mci_card_busy(slot-mmc));
+}
+
static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool
force_clkinit)
{
struct dw_mci *host = slot-host;
@@ -899,6 +925,8 @@ static void dw_mci_setup_bus(struct dw_mci_slot
*slot, bool force_clkinit)
/* We must continue to set bit 28 in CMD until the change is
complete */
if (host-state == STATE_WAITING_CMD11_DONE)
sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH;
+ else
+ dw_mci_wait_busy(slot);
hmm...I would suggest you to call dw_mci_wait_busy() from inside
mci_send_cmd(), seems like dw_mmc hangs while sending update clock cmd
in multiple cases.see [1]
[1]: http://permalink.gmane.org/gmane.linux.kernel.mmc/31140
I think this patch is more reasonable.
So I will resend patches based on this patch.
thank you!
I have tested your patches instead [1] above and they do not solve my
issue:
Board: odroid-xu3/exynos5422/dw_mmc_250a.
MMC card: absent, broken-cd quirk
SD card: present
I doubt $SUBJECT patch in current form can resolve you issue. I have
already given comments on $subject patch.
Can you try out below patch (I have not tested yet) on top of $SUBJECT
patch?
===
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index b0b57e3..ea87844 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -101,6 +101,7 @@ struct idmac_desc {
#endif /* CONFIG_MMC_DW_IDMAC */
static int dw_mci_card_busy(struct mmc_host *mmc);
+static void dw_mci_wait_busy(struct dw_mci_slot *slot);
static bool dw_mci_reset(struct dw_mci *host);
static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
@@ -874,16 +875,22 @@ static void mci_send_cmd(struct dw_mci_slot
*slot, u32 cmd, u32 arg)
struct dw_mci *host = slot-host;
unsigned long timeout = jiffies + msecs_to_jiffies(500);
unsigned int cmd_status = 0;
+ int re_try =
Re: [PATCH 12/14] ARM: dts: Introduce STM32F429 MCU
Hi Maxime,
Am Donnerstag, den 12.02.2015, 18:46 +0100 schrieb Maxime Coquelin:
[...]
+ soc {
+ reset_ahb1: reset@40023810 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023810 0x4;
+ };
+
+ reset_ahb2: reset@40023814 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023814 0x4;
+ };
+
+ reset_ahb3: reset@40023818 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023818 0x4;
+ };
+
+ reset_apb1: reset@40023820 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023820 0x4;
+ };
+
+ reset_apb2: reset@40023824 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023824 0x4;
+ };
These are mostly consecutive, single registers. I wonder if these are
part of the same IP block and thus should be grouped together into the
same reset controller node?
regards
Philipp
--
To unsubscribe from this list: send the line 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 04/14] reset: Add reset_controller_of_init() function
Hi Maxime,
Am Donnerstag, den 12.02.2015, 18:45 +0100 schrieb Maxime Coquelin:
Some platforms need to initialize the reset controller before the timers.
This patch introduces a reset_controller_of_init() function that can be
called before the timers intialization.
Signed-off-by: Maxime Coquelin mcoquelin.st...@gmail.com
---
drivers/reset/core.c | 20
include/asm-generic/vmlinux.lds.h | 4 +++-
include/linux/reset-controller.h | 6 ++
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 7955e00..18ee579 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -86,6 +86,26 @@ void reset_controller_unregister(struct
reset_controller_dev *rcdev)
}
EXPORT_SYMBOL_GPL(reset_controller_unregister);
+extern struct of_device_id __reset_ctrl_of_table[];
+
+static const struct of_device_id __reset_ctrl_of_table_sentinel
+ __used __section(__reset_ctrl_of_table_end);
+
+void __init reset_controller_of_init(void)
The patch looks fine to me, but this function is missing a kerneldoc
comment.
+{
+ struct device_node *np;
+ const struct of_device_id *match;
+ of_init_fn_1 init_func;
+
+ for_each_matching_node_and_match(np, __reset_ctrl_of_table, match) {
+ if (!of_device_is_available(np))
+ continue;
+
+ init_func = match-data;
+ init_func(np);
+ }
+}
+
/**
* reset_control_reset - reset the controlled device
* @rstc: reset controller
regards
Philipp
--
To unsubscribe from this list: send the line 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/5] pm: domains: quieten down generic pm domains
On Mon, May 05, 2014 at 12:36:25AM +0200, Rafael J. Wysocki wrote: On Friday, May 02, 2014 11:24:45 AM Ulf Hansson wrote: On 1 May 2014 01:46, Rafael J. Wysocki r...@rjwysocki.net wrote: On Sunday, April 27, 2014 02:28:50 PM Russell King wrote: Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Rafael J. Wysocki r...@rjwysocki.net Since you need this one and [2/5] for the rest of the patchset, please feel free to take them through your tree if that's convenient. Unless it complicates things for Russell, I would prefer if this could go via Rafael's tree. I have a quite big patchset for the PM domain, it would help me if I have a single point to base my work upon. No problem for me, but I'm not sure about what Russell things. Well, it seems nothing happened with these patches, and they're still something I have (and I've just updated them to changes in 3.19.) What are we going to do about them? -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line 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/5] ARM: dove: create a proper PMU driver for power domains, PMU IRQs and resets
On Fri, Feb 13, 2015 at 01:29:25PM +, Russell King - ARM Linux wrote: On Mon, Apr 28, 2014 at 01:55:40PM +0200, Ulf Hansson wrote: On 27 April 2014 15:29, Russell King rmk+ker...@arm.linux.org.uk wrote: The PMU device contains an interrupt controller, power control and resets. The interrupt controller is a little sub-standard in that there is no race free way to clear down pending interrupts, so we try to avoid problems by reducing the window as much as possible, and clearing as infrequently as possible. The interrupt support is implemented using an IRQ domain, and the parent interrupt referenced in the standard DT way. The power domains and reset support is closely related - there is a defined sequence for powering down a domain which is tightly coupled with asserting the reset. Hence, it makes sense to group these two together. This patch adds the core PMU driver: power domains must be defined in the DT file in order to make use of them. The reset controller can be referenced in the standard way for reset controllers. Hi Russell, This patch would be simplified if this was based upon the not yet merged patchset from Tomasz Figa, [PATCH v3 0/3] Generic Device Tree based power domain look-up. For example you would likely not need to add some of the marvel specific DT bindings, and you wouldn’t need the bus_notifiers to add devices to the power domain. I guess I just though it could be useful input to consider while going forward, unless you already knew. In 3.19, I notice something of an odd behaviour. My vMeta driver has runtime PM support enabled. When I explicitly register the PM domain in the pmu driver via a bus notifier, I see: root@cubox:~# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary domain status slaves /device runtime status -- gpu-domain on /devices/platform/vivante/etnaviv-gpu,2dactive vpu-domain off /devices/platform/mbus/mbus:internal-regs/f1c0.video-decoder suspended But when I disable that, and let the generic code do the registration, I instead get: root@cubox:~# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary domain status slaves /device runtime status -- gpu-domain on /devices/platform/vivante/etnaviv-gpu,2dactive vpu-domain on /devices/platform/mbus/mbus:internal-regs/f1c0.video-decoder suspended The difference being that the vpu domain remains powered. The only difference code-wise seems to be when genpd_dev_pm_attach() is called. In the working case, it's before the device is considered for probing. In the non-working case, it's just before the device is probed. With debugging enabled in the PM domain code, with the former case I get: Added domain provider from /mbus/internal-regs/power-management@d/vpu-domain platform f1c0.video-decoder: adding to PM domain vpu-domain platform f1c0.video-decoder: __pm_genpd_add_device() With the latter non-working case: Added domain provider from /mbus/internal-regs/power-management@d/vpu-domain ... ap510-vmeta f1c0.video-decoder: adding to PM domain vpu-domain ap510-vmeta f1c0.video-decoder: __pm_genpd_add_device() vpu-domain: Power-on latency exceeded, new value 1578 ns Neither of these debug messages provide much hint as to what the difference is, or the cause of the PM domain code being de-sync'd with its devices. Maybe the PM code needs more debugging in it, and maybe the debugfs file should always be present if debugfs support is enabled? The vmeta driver does this in its probe function: pm_runtime_use_autosuspend(vi-dev); pm_runtime_set_autosuspend_delay(vi-dev, 100); pm_runtime_enable(vi-dev); since it doesn't touch the hardware, and the hardware starts off at boot time in suspended mode. I think what's going on is that there's a difference in the expectations from the PM domain code vs the runtime PM code. I refer to section 5 of the runtime PM documentation: | 5. Runtime PM Initialization, Device Probing and Removal | | Initially, the runtime PM is disabled for all devices, which means that the | majority of the runtime PM helper functions described in Section 4 will return | -EAGAIN until pm_runtime_enable() is called for the device. | | In addition to that, the initial runtime PM status of all devices is | 'suspended', but it need not reflect the actual physical state of the device. | Thus, if the device is initially active (i.e. it is able to process I/O), its | runtime PM status must be changed
[PATCH 8/9] arm/dts: am57xx-beagle-x15.dts: add HDMI
AM57xx Beagle X15 has a HDMI output. This patch adds the device tree
nodes required for HDMI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicetree@vger.kernel.org
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 80 +
1 file changed, 80 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 49edbda68cd5..0b838d34b8a1 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -19,6 +19,7 @@
aliases {
rtc0 = mcp_rtc;
rtc1 = tps659038_rtc;
+ display0 = hdmi0;
};
memory {
@@ -80,6 +81,51 @@
default-state = off;
};
};
+
+ hdmi0: connector {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = a;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+ };
+
+ tpd12s015: encoder {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = gpio7 10 GPIO_ACTIVE_HIGH, /* gpio7_10, CT CP HPD
*/
+ gpio6 28 GPIO_ACTIVE_HIGH, /* gpio6_28, LS OE */
+ gpio7 12 GPIO_ACTIVE_HIGH; /* gpio7_12/sp1_cs2,
HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
};
dra7_pmx_core {
@@ -99,6 +145,13 @@
;
};
+ hdmi_pins: pinmux_hdmi_pins {
+ pinctrl-single,pins =
+ 0x408 (PIN_INPUT | MUX_MODE1) /*
i2c2_sda.hdmi1_ddc_scl */
+ 0x40c (PIN_INPUT | MUX_MODE1) /*
i2c2_scl.hdmi1_ddc_sda */
+ ;
+ };
+
i2c3_pins_default: i2c3_pins_default {
pinctrl-single,pins =
0x2a4 (PIN_INPUT| MUX_MODE10) /*
mcasp1_aclkx.i2c3_sda */
@@ -164,6 +217,13 @@
;
};
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x3b0 (PIN_OUTPUT | MUX_MODE14) /* gpio7_10
CT_CP_HPD */
+ 0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD
*/
+ 0x370 (PIN_OUTPUT | MUX_MODE14) /* gpio6_28
LS_OE */
+ ;
+ };
};
i2c1 {
@@ -403,3 +463,23 @@
pinctrl-names = default;
pinctrl-0 = usb1_pins;
};
+
+dss {
+ status = ok;
+
+ vdda_video-supply = ldoln_reg;
+};
+
+hdmi {
+ status = ok;
+ vdda-supply = ldo3_reg;
+
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_pins;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+ };
+};
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/9] arm/dts: dra72-evm.dts: add HDMI
DRA72 EVM has a HDMI output. This patch adds the device tree nodes
required for HDMI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicetree@vger.kernel.org
---
arch/arm/boot/dts/dra72-evm.dts | 111
1 file changed, 111 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 89085d066c65..85f9aa4fc94f 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include dra72x.dtsi
+#include dt-bindings/gpio/gpio.h
/ {
model = TI DRA722;
@@ -18,12 +19,61 @@
reg = 0x8000 0x4000; /* 1024 MB */
};
+ aliases {
+ display0 = hdmi0;
+ };
+
evm_3v3: fixedregulator-evm_3v3 {
compatible = regulator-fixed;
regulator-name = evm_3v3;
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
};
+
+ hdmi0: connector {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = a;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+ };
+
+ tpd12s015: encoder {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = pcf_hdmi 4 GPIO_ACTIVE_HIGH, /* P4, CT CP HPD */
+ pcf_hdmi 5 GPIO_ACTIVE_HIGH, /* P5, LS OE */
+ gpio7 12 GPIO_ACTIVE_HIGH; /* gpio7_12/sp1_cs2,
HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
};
dra7_pmx_core {
@@ -34,6 +84,13 @@
;
};
+ i2c5_pins: pinmux_i2c5_pins {
+ pinctrl-single,pins =
+ 0x2b4 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr0.i2c5_sda
*/
+ 0x2b8 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr1.i2c5_scl
*/
+ ;
+ };
+
nand_default: nand_default {
pinctrl-single,pins =
0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0 */
@@ -121,6 +178,19 @@
0x418 (MUX_MODE15)/* wakeup0.off */
;
};
+
+ hdmi_pins: pinmux_hdmi_pins {
+ pinctrl-single,pins =
+ 0x408 (PIN_INPUT | MUX_MODE1) /* i2c2_sda.hdmi1_ddc_scl
*/
+ 0x40c (PIN_INPUT | MUX_MODE1) /* i2c2_scl.hdmi1_ddc_sda
*/
+ ;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD
*/
+ ;
+ };
};
i2c1 {
@@ -245,6 +315,27 @@
};
};
+i2c5 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c5_pins;
+ clock-frequency = 40;
+
+ pcf_hdmi: pcf8575@26 {
+ compatible = nxp,pcf8575;
+ reg = 0x26;
+ gpio-controller;
+ #gpio-cells = 2;
+ /*
+* initial state is used here to keep the mdio interface
+* selected on RU89 through SEL_VIN4_MUX_S0, VIN2_S1 and
+* VIN2_S0 driven high otherwise Ethernet stops working
+* VIN6_SEL_S0 is low, thus selecting McASP3 over VIN6
+*/
+ lines-initial-states = 0x0f2b;
+ };
+};
+
uart1 {
status = okay;
};
@@ -461,3 +552,23 @@
pinctrl-0 = dcan1_pins_default;
pinctrl-1 = dcan1_pins_sleep;
};
+
+dss {
+ status = ok;
+
+ vdda_video-supply = ldo5_reg;
+};
+
+hdmi {
+ status = ok;
+ vdda-supply = ldo3_reg;
+
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_pins;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+ };
+};
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] arm/dts: dra7.dtsi: add DSS support
DRA7xxx contains a very similar DSS to OMAP5. The main differences are:
* no DSI or RFBI support.
* 1 or 2 dedicated video PLLs.
* need to do additional configuration to the DRA7 CONTROL module.
DRA72xx has only one video PLL, and DRA74xx has two.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicetree@vger.kernel.org
---
arch/arm/boot/dts/dra7.dtsi | 38 ++
arch/arm/boot/dts/dra72x.dtsi | 11 +++
arch/arm/boot/dts/dra74x.dtsi | 15 +++
3 files changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 22771bc1643a..fc35a8a06d95 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1421,6 +1421,44 @@
clocks = sys_clkin1;
status = disabled;
};
+
+ dss: dss@5800 {
+ compatible = ti,dra7-dss;
+ /* 'reg' defined in dra72x.dtsi and dra74x.dtsi */
+ /* 'clocks' defined in dra72x.dtsi and dra74x.dtsi */
+ status = disabled;
+ ti,hwmods = dss_core;
+ /* CTRL_CORE_DSS_PLL_CONTROL */
+ syscon-pll-ctrl = dra7_ctrl_core 0x538;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@58001000 {
+ compatible = ti,dra7-dispc;
+ reg = 0x58001000 0x1000;
+ interrupts = GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ clocks = dss_dss_clk;
+ clock-names = fck;
+ /* CTRL_CORE_SMA_SW_1 */
+ syscon-pol = dra7_ctrl_core 0x534;
+ };
+
+ hdmi: encoder@5806 {
+ compatible = ti,dra7-hdmi;
+ reg = 0x5804 0x200,
+ 0x58040200 0x80,
+ 0x58040300 0x80,
+ 0x5806 0x19000;
+ reg-names = wp, pll, phy, core;
+ interrupts = GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ ti,hwmods = dss_hdmi;
+ clocks = dss_48mhz_clk, dss_hdmi_clk;
+ clock-names = fck, sys_clk;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index e5a3d23a3df1..0866866c8e94 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -28,3 +28,14 @@
interrupts = GIC_SPI DIRECT_IRQ(131) IRQ_TYPE_LEVEL_HIGH;
};
};
+
+dss {
+ reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20;
+ reg-names = dss, pll1_clkctrl, pll1;
+
+ clocks = dss_dss_clk,
+dss_video1_clk;
+ clock-names = fck, video1_clk;
+};
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index 10173fab1a15..1a4f4970aaad 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -67,3 +67,18 @@
};
};
};
+
+dss {
+ reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20,
+ 0x58005054 0x4,
+ 0x58005300 0x20;
+ reg-names = dss, pll1_clkctrl, pll1,
+ pll2_clkctrl, pll2;
+
+ clocks = dss_dss_clk,
+dss_video1_clk,
+dss_video2_clk;
+ clock-names = fck, video1_clk, video2_clk;
+};
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk
We need set-rate-parent flags for the display's clock path so that the
DSS driver can change the clock rate of the PLL.
This patchs adds the ti,set-rate-parent flag to 'dss_dss_clk' clock
node, which is only a gate clock, allowing the setting of the clock rate
to propagate to the PLL.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicetree@vger.kernel.org
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 4bdcbd61ce47..0d76233840e6 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1451,6 +1451,7 @@
clocks = dpll_per_h12x2_ck;
ti,bit-shift = 8;
reg = 0x1120;
+ ti,set-rate-parent;
};
dss_hdmi_clk: dss_hdmi_clk {
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v9 01/20] clk: divider: Correct parent clk round rate if no bestdiv is normally found
On 12/02/15 15:41, Sascha Hauer wrote: Tomis patch is based on the assumption that clk_set_rate(clk_round_rate(rate)) is equal to clk_round_rate(rate). So when this assumption is wrong then it should simply be reverted. When is it not equal? I agree that doing clk_set_rate(clk, clk_round_rate(clk, rate)) is pointless, but shouldn't it still work? And we can forget about clk_round_rate. Without my patch, this would behave oddly also: rate = clk_get_rate(clk); clk_set_rate(clk, rate); The end result could be something else than 'rate'. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/5] ARM: dove: create a proper PMU driver for power domains, PMU IRQs and resets
On Mon, Apr 28, 2014 at 01:55:40PM +0200, Ulf Hansson wrote: On 27 April 2014 15:29, Russell King rmk+ker...@arm.linux.org.uk wrote: The PMU device contains an interrupt controller, power control and resets. The interrupt controller is a little sub-standard in that there is no race free way to clear down pending interrupts, so we try to avoid problems by reducing the window as much as possible, and clearing as infrequently as possible. The interrupt support is implemented using an IRQ domain, and the parent interrupt referenced in the standard DT way. The power domains and reset support is closely related - there is a defined sequence for powering down a domain which is tightly coupled with asserting the reset. Hence, it makes sense to group these two together. This patch adds the core PMU driver: power domains must be defined in the DT file in order to make use of them. The reset controller can be referenced in the standard way for reset controllers. Hi Russell, This patch would be simplified if this was based upon the not yet merged patchset from Tomasz Figa, [PATCH v3 0/3] Generic Device Tree based power domain look-up. For example you would likely not need to add some of the marvel specific DT bindings, and you wouldn’t need the bus_notifiers to add devices to the power domain. I guess I just though it could be useful input to consider while going forward, unless you already knew. In 3.19, I notice something of an odd behaviour. My vMeta driver has runtime PM support enabled. When I explicitly register the PM domain in the pmu driver via a bus notifier, I see: root@cubox:~# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary domain status slaves /device runtime status -- gpu-domain on /devices/platform/vivante/etnaviv-gpu,2dactive vpu-domain off /devices/platform/mbus/mbus:internal-regs/f1c0.video-decoder suspended But when I disable that, and let the generic code do the registration, I instead get: root@cubox:~# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary domain status slaves /device runtime status -- gpu-domain on /devices/platform/vivante/etnaviv-gpu,2dactive vpu-domain on /devices/platform/mbus/mbus:internal-regs/f1c0.video-decoder suspended The difference being that the vpu domain remains powered. The only difference code-wise seems to be when genpd_dev_pm_attach() is called. In the working case, it's before the device is considered for probing. In the non-working case, it's just before the device is probed. With debugging enabled in the PM domain code, with the former case I get: Added domain provider from /mbus/internal-regs/power-management@d/vpu-domain platform f1c0.video-decoder: adding to PM domain vpu-domain platform f1c0.video-decoder: __pm_genpd_add_device() With the latter non-working case: Added domain provider from /mbus/internal-regs/power-management@d/vpu-domain ... ap510-vmeta f1c0.video-decoder: adding to PM domain vpu-domain ap510-vmeta f1c0.video-decoder: __pm_genpd_add_device() vpu-domain: Power-on latency exceeded, new value 1578 ns Neither of these debug messages provide much hint as to what the difference is, or the cause of the PM domain code being de-sync'd with its devices. Maybe the PM code needs more debugging in it, and maybe the debugfs file should always be present if debugfs support is enabled? -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/14] ARM: dts: Introduce STM32F429 MCU
Hi Philipp,
2015-02-13 12:47 GMT+01:00 Philipp Zabel p.za...@pengutronix.de:
Hi Maxime,
Am Donnerstag, den 12.02.2015, 18:46 +0100 schrieb Maxime Coquelin:
[...]
+ soc {
+ reset_ahb1: reset@40023810 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023810 0x4;
+ };
+
+ reset_ahb2: reset@40023814 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023814 0x4;
+ };
+
+ reset_ahb3: reset@40023818 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023818 0x4;
+ };
+
+ reset_apb1: reset@40023820 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023820 0x4;
+ };
+
+ reset_apb2: reset@40023824 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023824 0x4;
+ };
These are mostly consecutive, single registers. I wonder if these are
part of the same IP block and thus should be grouped together into the
same reset controller node?
What I could to is to have two instances. One for AHB and one for APB domain.
Doing this, I will have one instance per domain, and only consecutive registers.
Is it fine for you?
Thanks,
Maxime
regards
Philipp
--
To unsubscribe from this list: send the line 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/5] ARM: dove: create a proper PMU driver for power domains, PMU IRQs and resets
On Fri, Feb 13, 2015 at 02:11:52PM +, Russell King - ARM Linux wrote:
I think what's going on is that there's a difference in the expectations
from the PM domain code vs the runtime PM code. I refer to section 5
of the runtime PM documentation:
| 5. Runtime PM Initialization, Device Probing and Removal
|
| Initially, the runtime PM is disabled for all devices, which means that the
| majority of the runtime PM helper functions described in Section 4 will
return
| -EAGAIN until pm_runtime_enable() is called for the device.
|
| In addition to that, the initial runtime PM status of all devices is
| 'suspended', but it need not reflect the actual physical state of the
device.
| Thus, if the device is initially active (i.e. it is able to process I/O),
its
| runtime PM status must be changed to 'active', with the help of
| pm_runtime_set_active(), before pm_runtime_enable() is called for the
device.
However, the PM domain code seems to always power up the PM domain when
a device is attached to it:
int genpd_dev_pm_attach(struct device *dev)
{
...
pm_genpd_poweron(pd);
return 0;
}
EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
So, the PM domain code ends up disagreeing with the runtime PM code about
the state of the device.
I think your commit (2ed127697eb1 PM / Domains: Power on the PM domain
right after attach completes) is fundamentally wrong. The assertion
you make in there is built upon the assumption that every driver will
call pm_runtime_set_active(), which is not an assumption you can make.
Instead, you should be doing is to hook into __pm_runtime_set_status()
and use that to trigger the PM domain power up so that the runtime PM
and PM domain state is always in step with each other.
What I'm certain of is that the current situation is just totally crazy.
There are around 150 drivers in the kernel tree which do not call
pm_runtime_set_active() before calling pm_runtime_enable(), so the
assertion in the PM domains commit above is wrong. Some of them are
only saved because they do a pm_runtime_get() immediately after
pm_runtime_enable(), but that's in no way guaranteed - others do
neither. So, for this to work properly, we need to address this
issue _correctly_ rather than papering over the problem.
Here's a patch which solves the issue for me along the lines which I
described above. I'm introducing a new callback - runtime_set_status()
which the PM domain code uses to be notified of the runtime PM status
updates while RPM is disabled. This callback will only occur from
__pm_runtime_set_status(), which can only be used while runtime PM is
disabled.
I believe it's safe - if we think that a PM domain is powered down, and
the runtime PM status is then set active, it's clear that the PM domain
absolutely must transition to active mode as well. If the runtime PM
status is set to suspended, then the PM domain code can transition to
off state.
I've left some of my debugging in place in the patch below as that's
exactly the code I've tested.
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 751a8859a4ab..1616faadf904 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -5,7 +5,7 @@
*
* This file is released under the GPLv2.
*/
-
+#define DEBUG
#include linux/kernel.h
#include linux/io.h
#include linux/platform_device.h
@@ -158,6 +158,8 @@ static int genpd_power_on(struct generic_pm_domain *genpd)
s64 elapsed_ns;
int ret;
+ pr_debug(%s: %s()\n, genpd-name, __func__);
+
if (!genpd-power_on)
return 0;
@@ -219,6 +221,10 @@ static int __pm_genpd_poweron(struct generic_pm_domain
*genpd)
DEFINE_WAIT(wait);
int ret = 0;
+ pr_debug(%s: %s() status %u prepared %d spo %u\n,
+ genpd-name, __func__, genpd-status, genpd-prepared_count,
+ genpd-suspend_power_off);
+
/* If the domain's master is being waited for, we have to wait too. */
for (;;) {
prepare_to_wait(genpd-status_wait_queue, wait,
@@ -741,6 +747,20 @@ static int pm_genpd_runtime_resume(struct device *dev)
return 0;
}
+static int pm_genpd_runtime_set_status(struct device *dev)
+{
+ int ret;
+
+ dev_dbg(dev, %s()\n, __func__);
+
+ if (pm_runtime_suspended(dev))
+ ret = pm_genpd_runtime_suspend(dev);
+ else
+ ret = pm_genpd_runtime_resume(dev);
+
+ return ret;
+}
+
static bool pd_ignore_unused;
static int __init pd_ignore_unused_setup(char *__unused)
{
@@ -1907,6 +1927,7 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
genpd-max_off_time_changed = true;
genpd-domain.ops.runtime_suspend = pm_genpd_runtime_suspend;
genpd-domain.ops.runtime_resume = pm_genpd_runtime_resume;
+ genpd-domain.ops.runtime_set_status = pm_genpd_runtime_set_status;
genpd-domain.ops.prepare = pm_genpd_prepare;
Re: [PATCH 04/14] reset: Add reset_controller_of_init() function
Hi Philipp, 2015-02-13 12:49 GMT+01:00 Philipp Zabel p.za...@pengutronix.de: Hi Maxime, Am Donnerstag, den 12.02.2015, 18:45 +0100 schrieb Maxime Coquelin: Some platforms need to initialize the reset controller before the timers. This patch introduces a reset_controller_of_init() function that can be called before the timers intialization. Signed-off-by: Maxime Coquelin mcoquelin.st...@gmail.com --- drivers/reset/core.c | 20 include/asm-generic/vmlinux.lds.h | 4 +++- include/linux/reset-controller.h | 6 ++ 3 files changed, 29 insertions(+), 1 deletion(-) diff --git a/drivers/reset/core.c b/drivers/reset/core.c index 7955e00..18ee579 100644 --- a/drivers/reset/core.c +++ b/drivers/reset/core.c @@ -86,6 +86,26 @@ void reset_controller_unregister(struct reset_controller_dev *rcdev) } EXPORT_SYMBOL_GPL(reset_controller_unregister); +extern struct of_device_id __reset_ctrl_of_table[]; + +static const struct of_device_id __reset_ctrl_of_table_sentinel + __used __section(__reset_ctrl_of_table_end); + +void __init reset_controller_of_init(void) The patch looks fine to me, but this function is missing a kerneldoc comment. Right! It will be fixed in the v2. Thanks, Maxime -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/14] ARM: dts: Introduce STM32F429 MCU
Hi Maxime,
Am Freitag, den 13.02.2015, 16:59 +0100 schrieb Maxime Coquelin:
Hi Philipp,
2015-02-13 12:47 GMT+01:00 Philipp Zabel p.za...@pengutronix.de:
Hi Maxime,
Am Donnerstag, den 12.02.2015, 18:46 +0100 schrieb Maxime Coquelin:
[...]
+ soc {
+ reset_ahb1: reset@40023810 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023810 0x4;
+ };
+
+ reset_ahb2: reset@40023814 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023814 0x4;
+ };
+
+ reset_ahb3: reset@40023818 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023818 0x4;
+ };
+
+ reset_apb1: reset@40023820 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023820 0x4;
+ };
+
+ reset_apb2: reset@40023824 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023824 0x4;
+ };
These are mostly consecutive, single registers. I wonder if these are
part of the same IP block and thus should be grouped together into the
same reset controller node?
What I could to is to have two instances. One for AHB and one for APB domain.
Doing this, I will have one instance per domain, and only consecutive
registers.
Is it fine for you?
Looking at
http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
Table 34 (RCC register map and reset values), I'd say there is a single
Reset and Clock Control device at 0x40023800 - 0x40023884:
soc {
rcc: rcc@40023800 {
#clock-cells = 1;
#reset-cells = 1;
compatible = st,stm32-rcc;
reg = 0x40023800 0x84;
};
...
If you really want to describe the reset controller parts (offsets +0x10
to +0x24) in a separate node, I won't argue against it too long,
although this is a somewhat arbitrary decision.
In any case, the whole register at offset +0x1c is reserved, so there is
no reason to split the reset controller. It is ok to have unused ranges
as is already the case with reserved bits inside the used registers.
regards
Philipp
--
To unsubscribe from this list: send the line 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] clk: Add PWM clock driver
On 12/12/14 02:47, Philipp Zabel wrote:
+
+const struct clk_ops clk_pwm_ops = {
static?
+ .prepare = clk_pwm_prepare,
+ .unprepare = clk_pwm_unprepare,
+ .recalc_rate = clk_pwm_recalc_rate,
+};
+
+int clk_pwm_probe(struct platform_device *pdev)
static?
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct clk_init_data init;
+ struct clk_pwm *clk_pwm;
+ struct pwm_device *pwm;
+ const char *clk_name;
+ struct clk *clk;
+ int ret;
[...]
+}
+
+int clk_pwm_remove(struct platform_device *pdev)
static?
+{
+ of_clk_del_provider(pdev-dev.of_node);
+
+ return 0;
+}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: perf: Add support for Scorpion PMUs
Scorpion supports a set of local performance monitor event
selection registers (LPM) sitting behind a cp15 based interface
that extend the architected PMU events to include Scorpion CPU
and Venum VFP specific events. To use these events the user is
expected to program the lpm register with the event code shifted
into the group they care about and then point the PMNx event at
that region+group combo by writing a LPMn_GROUPx event. Add
support for this hardware.
Note: the raw event number is a pure software construct that
allows us to map the multi-dimensional number space of regions,
groups, and event codes into a flat event number space suitable
for use by the perf framework.
This is based on code originally written by Ashwin Chaugule and
Neil Leeder [1] massaged to become similar to the Krait PMU
support code.
[1]
https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/arch/arm/kernel/perf_event_msm.c?h=msm-3.4
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Neil Leeder nlee...@codeaurora.org
Cc: Ashwin Chaugule ashw...@codeaurora.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
Documentation/devicetree/bindings/arm/pmu.txt | 2 +
arch/arm/kernel/perf_event_cpu.c | 2 +
arch/arm/kernel/perf_event_v7.c | 417 ++
3 files changed, 421 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/pmu.txt
b/Documentation/devicetree/bindings/arm/pmu.txt
index 75ef91d08f3b..6e54a9d88b7a 100644
--- a/Documentation/devicetree/bindings/arm/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/pmu.txt
@@ -18,6 +18,8 @@ Required properties:
arm,arm11mpcore-pmu
arm,arm1176-pmu
arm,arm1136-pmu
+ qcom,scorpion-pmu
+ qcom,scorpion-mp-pmu
qcom,krait-pmu
- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a
per-cpu
interrupt (PPI) then 1 interrupt should be specified.
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index dd9acc95ebc0..4fbf1085f75a 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -243,6 +243,8 @@ static struct of_device_id cpu_pmu_of_device_ids[] = {
{.compatible = arm,arm1176-pmu, .data = armv6_1176_pmu_init},
{.compatible = arm,arm1136-pmu, .data = armv6_1136_pmu_init},
{.compatible = qcom,krait-pmu,.data = krait_pmu_init},
+ {.compatible = qcom,scorpion-pmu, .data = scorpion_pmu_init},
+ {.compatible = qcom,scorpion-mp-pmu, .data = scorpion_mp_pmu_init},
{},
};
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 84a3ec3bc592..cafa4a6b0fb4 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -140,6 +140,23 @@ enum krait_perf_types {
KRAIT_PERFCTR_L1_DTLB_ACCESS= 0x12210,
};
+/* ARMv7 Scorpion specific event types */
+enum scorpion_perf_types {
+ SCORPION_LPM0_GROUP0= 0x4c,
+ SCORPION_LPM1_GROUP0= 0x50,
+ SCORPION_LPM2_GROUP0= 0x54,
+ SCORPION_L2LPM_GROUP0 = 0x58,
+ SCORPION_VLPM_GROUP0= 0x5c,
+
+ SCORPION_ICACHE_ACCESS = 0x10053,
+ SCORPION_ICACHE_MISS= 0x10052,
+
+ SCORPION_DTLB_ACCESS= 0x12013,
+ SCORPION_DTLB_MISS = 0x12012,
+
+ SCORPION_ITLB_MISS = 0x12021,
+};
+
/*
* Cortex-A8 HW events mapping
*
@@ -482,6 +499,49 @@ static const unsigned
krait_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
};
/*
+ * Scorpion HW events mapping
+ */
+static const unsigned scorpion_perf_map[PERF_COUNT_HW_MAX] = {
+ PERF_MAP_ALL_UNSUPPORTED,
+ [PERF_COUNT_HW_CPU_CYCLES] = ARMV7_PERFCTR_CPU_CYCLES,
+ [PERF_COUNT_HW_INSTRUCTIONS]= ARMV7_PERFCTR_INSTR_EXECUTED,
+ [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = ARMV7_PERFCTR_PC_WRITE,
+ [PERF_COUNT_HW_BRANCH_MISSES] = ARMV7_PERFCTR_PC_BRANCH_MIS_PRED,
+ [PERF_COUNT_HW_BUS_CYCLES] = ARMV7_PERFCTR_CLOCK_CYCLES,
+};
+
+static const unsigned scorpion_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
+ [PERF_COUNT_HW_CACHE_OP_MAX]
+ [PERF_COUNT_HW_CACHE_RESULT_MAX] = {
+ PERF_CACHE_MAP_ALL_UNSUPPORTED,
+ /*
+* The performance counters don't differentiate between read and write
+* accesses/misses so this isn't strictly correct, but it's the best we
+* can do. Writes and reads get combined.
+*/
+ [C(L1D)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV7_PERFCTR_L1_DCACHE_ACCESS,
+ [C(L1D)][C(OP_READ)][C(RESULT_MISS)] = ARMV7_PERFCTR_L1_DCACHE_REFILL,
+
Re: [PATCH v4] clk: Add PWM clock driver
Hi Stephen,
Am Freitag, den 13.02.2015, 09:16 -0800 schrieb Stephen Boyd:
On 12/12/14 02:47, Philipp Zabel wrote:
+
+const struct clk_ops clk_pwm_ops = {
static?
[...]
+int clk_pwm_probe(struct platform_device *pdev)
static?
[...]
+int clk_pwm_remove(struct platform_device *pdev)
static?
Yes indeed. Next round will have this fixed, thank you.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] i8042: Kernel configuration handling for DT support
i8042_dt.h should be included when CONFIG_ARCH_MIGHT_HAVE_PC_SERIO and CONFIG_USE_OF are selected. It should be not necessary to create additional options in the kernel config. Signed-off-by: Roman Volkov v1...@v1ros.org --- drivers/input/serio/i8042.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/input/serio/i8042.h b/drivers/input/serio/i8042.h index fc080be..d2c1761 100644 --- a/drivers/input/serio/i8042.h +++ b/drivers/input/serio/i8042.h @@ -28,6 +28,9 @@ #include i8042-x86ia64io.h #elif defined(CONFIG_UNICORE32) #include i8042-unicore32io.h +#elif defined(CONFIG_ARCH_MIGHT_HAVE_PC_SERIO) defined(CONFIG_USE_OF) +#define SERIO_I8042_DT +#include i8042-dt.h #else #include i8042-io.h #endif -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] i8042: intel-8042 DT documentation
Documentation for 'intel,8042' DT compatible node.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
Signed-off-by: Roman Volkov v1...@v1ros.org
---
.../devicetree/bindings/input/intel-8042.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/intel-8042.txt
diff --git a/Documentation/devicetree/bindings/input/intel-8042.txt
b/Documentation/devicetree/bindings/input/intel-8042.txt
new file mode 100644
index 000..ab8a3e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/intel-8042.txt
@@ -0,0 +1,26 @@
+Intel 8042 Keyboard Controller
+
+Required properties:
+- compatible: should be intel,8042
+- regs: memory for keyboard controller
+- interrupts: usually, two interrupts should be specified (keyboard and aux).
+ However, only one interrupt is also allowed in case of absence of the
+ physical port in the controller. The i8042 driver must be loaded with
+ nokbd/noaux option in this case.
+- interrupt-names: interrupt names corresponding to numbers in the list.
+ kbd is the keyboard interrupt and aux is the auxiliary (mouse)
+ interrupt.
+- command-reg: offset in memory for command register
+- status-reg: offset in memory for status register
+- data-reg: offset in memory for data register
+
+Example:
+ i8042@d8008800 {
+ compatible = intel,8042;
+ regs = 0xd8008800 0x100;
+ interrupts = 23, 4;
+ interrupt-names = kbd, aux;
+ command-reg = 0x04;
+ status-reg = 0x04;
+ data-reg = 0x00;
+ };
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v9 01/20] clk: divider: Correct parent clk round rate if no bestdiv is normally found
On Fri, Feb 13, 2015 at 04:35:36PM +0200, Tomi Valkeinen wrote: On 12/02/15 15:41, Sascha Hauer wrote: Tomis patch is based on the assumption that clk_set_rate(clk_round_rate(rate)) is equal to clk_round_rate(rate). So when this assumption is wrong then it should simply be reverted. When is it not equal? I agree that doing clk_set_rate(clk, clk_round_rate(clk, rate)) is pointless, but shouldn't it still work? And we can forget about clk_round_rate. Without my patch, this would behave oddly also: rate = clk_get_rate(clk); clk_set_rate(clk, rate); The end result could be something else than 'rate'. I agree that it's a bit odd, but I think it has to be like this. Consider that you request a rate of 100Hz, but the clock can only produce 99.5Hz, so due to rounding clk_round_rate() returns 99Hz. Now when you request 99Hz from clk_set_rate() the 99.5Hz value can't be used because it's too high. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] clk: Add PWM clock driver
Some board designers, when running out of clock output pads, decide to
(mis)use PWM output pads to provide a clock to external components.
This driver supports this practice by providing an adapter between the
PWM and clock bindings in the device tree. As the PWM bindings specify
the period in the device tree, this is a fixed clock.
Tested-by: Janusz Uzycki j.uzy...@elproma.com.pl
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v4:
- Added missing static keywords, as pointed out by Stephen Boyd
- Turned to_clk_pwm into an inline function,
- added MODULE_AUTHOR/DESCRIPTION/LICENSE,
- and fixed PWM spelling issues, as pointed out by Thierry Reding
---
.../devicetree/bindings/clock/pwm-clock.txt| 26
drivers/clk/Kconfig| 7 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-pwm.c | 136 +
4 files changed, 170 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/pwm-clock.txt
create mode 100644 drivers/clk/clk-pwm.c
diff --git a/Documentation/devicetree/bindings/clock/pwm-clock.txt
b/Documentation/devicetree/bindings/clock/pwm-clock.txt
new file mode 100644
index 000..83db876
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/pwm-clock.txt
@@ -0,0 +1,26 @@
+Binding for an external clock signal driven by a PWM pin.
+
+This binding uses the common clock binding[1] and the common PWM binding[2].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/pwm/pwm.txt
+
+Required properties:
+- compatible : shall be pwm-clock.
+- #clock-cells : from common clock binding; shall be set to 0.
+- pwms : from common PWM binding; this determines the clock frequency
+ via the period given in the PWM specifier.
+
+Optional properties:
+- clock-output-names : From common clock binding.
+- clock-frequency : Exact output frequency, in case the PWM period
+ is not exact but was rounded to nanoseconds.
+
+Example:
+ clock {
+ compatible = pwm-clock;
+ #clock-cells = 0;
+ clock-frequency = 2500;
+ clock-output-names = mipi_mclk;
+ pwms = pwm2 0 40; /* 1 / 40 ns = 25 MHz */
+ };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 3f44f292..772d45e 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -129,6 +129,13 @@ config COMMON_CLK_PALMAS
This driver supports TI Palmas devices 32KHz output KG and KG_AUDIO
using common clock framework.
+config COMMON_CLK_PWM
+ tristate Clock driver for PWMs used as clock outputs
+ depends on PWM
+ ---help---
+ Adapter driver so that any PWM output can be (mis)used as clock signal
+ at 50% duty cycle.
+
config COMMON_CLK_PXA
def_bool COMMON_CLK ARCH_PXA
---help---
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d5fba5b..6a0c5cf 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_ARCH_U300) += clk-u300.o
obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
obj-$(CONFIG_COMMON_CLK_WM831X)+= clk-wm831x.o
obj-$(CONFIG_COMMON_CLK_XGENE) += clk-xgene.o
+obj-$(CONFIG_COMMON_CLK_PWM) += clk-pwm.o
obj-$(CONFIG_COMMON_CLK_AT91) += at91/
obj-$(CONFIG_ARCH_BCM_MOBILE) += bcm/
obj-$(CONFIG_ARCH_BERLIN) += berlin/
diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
new file mode 100644
index 000..328fcfc
--- /dev/null
+++ b/drivers/clk/clk-pwm.c
@@ -0,0 +1,136 @@
+/*
+ * Copyright (C) 2014 Philipp Zabel, Pengutronix
+ *
+ * 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.
+ *
+ * PWM (mis)used as clock output
+ */
+#include linux/clk-provider.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pwm.h
+
+struct clk_pwm {
+ struct clk_hw hw;
+ struct pwm_device *pwm;
+ u32 fixed_rate;
+};
+
+static inline struct clk_pwm *to_clk_pwm(struct clk_hw *hw)
+{
+ return container_of(hw, struct clk_pwm, hw);
+}
+
+static int clk_pwm_prepare(struct clk_hw *hw)
+{
+ struct clk_pwm *clk_pwm = to_clk_pwm(hw);
+
+ return pwm_enable(clk_pwm-pwm);
+}
+
+static void clk_pwm_unprepare(struct clk_hw *hw)
+{
+ struct clk_pwm *clk_pwm = to_clk_pwm(hw);
+
+ pwm_disable(clk_pwm-pwm);
+}
+
+static unsigned long clk_pwm_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ struct clk_pwm *clk_pwm = to_clk_pwm(hw);
+
+ return clk_pwm-fixed_rate;
+}
+
+static const struct clk_ops clk_pwm_ops = {
+ .prepare = clk_pwm_prepare,
+ .unprepare =
Re: [PATCH 12/14] ARM: dts: Introduce STM32F429 MCU
Am Freitag, den 13.02.2015, 17:41 +0100 schrieb Maxime Coquelin:
2015-02-13 17:25 GMT+01:00 Philipp Zabel p.za...@pengutronix.de:
Hi Maxime,
Am Freitag, den 13.02.2015, 16:59 +0100 schrieb Maxime Coquelin:
Hi Philipp,
2015-02-13 12:47 GMT+01:00 Philipp Zabel p.za...@pengutronix.de:
Hi Maxime,
Am Donnerstag, den 12.02.2015, 18:46 +0100 schrieb Maxime Coquelin:
[...]
+ soc {
+ reset_ahb1: reset@40023810 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023810 0x4;
+ };
+
+ reset_ahb2: reset@40023814 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023814 0x4;
+ };
+
+ reset_ahb3: reset@40023818 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023818 0x4;
+ };
+
+ reset_apb1: reset@40023820 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023820 0x4;
+ };
+
+ reset_apb2: reset@40023824 {
+ #reset-cells = 1;
+ compatible = st,stm32-reset;
+ reg = 0x40023824 0x4;
+ };
These are mostly consecutive, single registers. I wonder if these are
part of the same IP block and thus should be grouped together into the
same reset controller node?
What I could to is to have two instances. One for AHB and one for APB
domain.
Doing this, I will have one instance per domain, and only consecutive
registers.
Is it fine for you?
Looking at
http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
Table 34 (RCC register map and reset values), I'd say there is a single
Reset and Clock Control device at 0x40023800 - 0x40023884:
soc {
rcc: rcc@40023800 {
#clock-cells = 1;
#reset-cells = 1;
compatible = st,stm32-rcc;
reg = 0x40023800 0x84;
};
...
If you really want to describe the reset controller parts (offsets +0x10
to +0x24) in a separate node, I won't argue against it too long,
although this is a somewhat arbitrary decision.
In any case, the whole register at offset +0x1c is reserved, so there is
no reason to split the reset controller. It is ok to have unused ranges
as is already the case with reserved bits inside the used registers.
Ok. I understand your point.
But it will be more difficult at usage, because the node referencing
the fourth reset bit of apb2 register will have to pass 164 as
parameter.
It is error prone IMHO.
Other solution would be to add some defines for each reset line in the
DT-Bindings, as we do today for STi platform.
But it is giving an unneeded constraint between DT and reset trees.
That is a bit unfortunate, but providing the named constants in
include/dt-bindings/reset/ makes for a much better readable device tree,
so I'd prefer that solution, even if it means having to coordinate pull
requests.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] i8042: Add i8042_dt.h glue for DT support
This header file designed to be similar to other glue layers found
for i8042. The difference is that interrupt numbers, device address,
and other information should be retrieved from the device tree.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
Signed-off-by: Roman Volkov v1...@v1ros.org
---
drivers/input/serio/i8042-dt.h | 104 +
1 file changed, 104 insertions(+)
create mode 100644 drivers/input/serio/i8042-dt.h
diff --git a/drivers/input/serio/i8042-dt.h b/drivers/input/serio/i8042-dt.h
new file mode 100644
index 000..c0b319a
--- /dev/null
+++ b/drivers/input/serio/i8042-dt.h
@@ -0,0 +1,104 @@
+#ifndef _I8042_DT_H
+#define _I8042_DT_H
+
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_irq.h
+
+/*
+ * 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.
+ */
+
+static void __iomem *i8042_base;
+static unsigned int i8042_command_reg;
+static unsigned int i8042_status_reg;
+static unsigned int i8042_data_reg;
+#define I8042_COMMAND_REG i8042_command_reg
+#define I8042_STATUS_REG i8042_status_reg
+#define I8042_DATA_REG i8042_data_reg
+
+/*
+ * Names.
+ */
+
+#define I8042_KBD_PHYS_DESC i8042/serio0
+#define I8042_AUX_PHYS_DESC i8042/serio1
+#define I8042_MUX_PHYS_DESC i8042/serio%d
+
+/*
+ * IRQs.
+ */
+static int i8042_kbd_irq;
+static int i8042_aux_irq;
+#define I8042_KBD_IRQ i8042_kbd_irq
+#define I8042_AUX_IRQ i8042_aux_irq
+
+static inline int i8042_read_data(void)
+{
+ return readb(i8042_base + i8042_data_reg);
+}
+
+static inline int i8042_read_status(void)
+{
+ return readb(i8042_base + i8042_status_reg);
+}
+
+static inline void i8042_write_data(int val)
+{
+ writeb(val, i8042_base + i8042_data_reg);
+}
+
+static inline void i8042_write_command(int val)
+{
+ writeb(val, i8042_base + i8042_command_reg);
+}
+
+static inline int i8042_platform_init(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ const __be32 *regbase_p;
+ u64 regsize;
+ int status;
+
+ regbase_p = of_get_address(np, 0, regsize, NULL);
+ if (!regbase_p)
+ return -EINVAL;
+
+ status = of_property_read_u32(np, command-reg, i8042_command_reg);
+ if (status)
+ return status;
+
+ status = of_property_read_u32(np, status-reg, i8042_status_reg);
+ if (status)
+ return status;
+
+ status = of_property_read_u32(np, data-reg, i8042_data_reg);
+ if (status)
+ return status;
+
+ if ((i8042_command_reg = regsize) || (i8042_status_reg = regsize) ||
+ (i8042_data_reg = regsize))
+ return -EINVAL;
+
+ i8042_kbd_irq = platform_get_irq_byname(pdev, kbd);
+ i8042_aux_irq = platform_get_irq_byname(pdev, aux);
+
+ i8042_base = ioremap((unsigned long)of_translate_address(np, regbase_p),
+ (unsigned long)regsize);
+ if (!i8042_base)
+ return -ENOMEM;
+
+ i8042_reset = true;
+
+ return 0;
+}
+
+static inline void i8042_platform_exit(void)
+{
+ if (i8042_base)
+ iounmap(i8042_base);
+}
+
+#endif
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] i8042: Prepare i8042 driver for DT support
Use platform_device_probe() instead of platform_create_bundle() when
compiled with DT support, since the latter function is not suitable for
handling the OF device tree.
The order of initialization is changed, since i8042_platform_init() for DT
requires initialized platform_device structure. To avoid searching of the
compatible node twice, the platform_device structure pointer must be passed
to the i8042_platform_init() function right after initialization by
platform_device_probe().
Signed-off-by: Tony Prisk li...@prisktech.co.nz
Signed-off-by: Roman Volkov v1...@v1ros.org
---
This is remaining weak place in the patch set. No ideas yet on
how to reduce the using of ifdefs to make code cleaner, need more discussion.
drivers/input/serio/i8042.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 2f09062..86a47ec 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -1421,16 +1421,32 @@ static int __init i8042_probe(struct platform_device
*dev)
int error;
i8042_platform_device = dev;
+#ifdef SERIO_I8042_DT
+ error = i8042_platform_init(dev);
+ if (error)
+ return error;
+ error = i8042_controller_check();
+ if (error)
+ goto out_platform_exit;
+#endif
if (i8042_reset) {
error = i8042_controller_selftest();
if (error)
+#ifdef SERIO_I8042_DT
+ goto out_platform_exit;
+#else
return error;
+#endif
}
error = i8042_controller_init();
if (error)
+#ifdef SERIO_I8042_DT
+ goto out_platform_exit;
+#else
return error;
+#endif
#ifdef CONFIG_X86
if (i8042_dritek)
@@ -1460,7 +1476,10 @@ static int __init i8042_probe(struct platform_device
*dev)
i8042_free_irqs();
i8042_controller_reset(false);
i8042_platform_device = NULL;
-
+#ifdef SERIO_I8042_DT
+ out_platform_exit:
+ i8042_platform_exit();
+#endif
return error;
}
@@ -1497,11 +1516,18 @@ static struct platform_driver i8042_driver = {
static int __init i8042_init(void)
{
+#ifndef SERIO_I8042_DT
struct platform_device *pdev;
+#endif
int err;
dbg_init();
+#ifdef SERIO_I8042_DT
+ err = platform_driver_probe(i8042_driver, i8042_probe);
+ if (err)
+ return err;
+#else
err = i8042_platform_init();
if (err)
return err;
@@ -1515,14 +1541,15 @@ static int __init i8042_init(void)
err = PTR_ERR(pdev);
goto err_platform_exit;
}
-
+#endif
panic_blink = i8042_panic_blink;
return 0;
-
+#ifndef SERIO_I8042_DT
err_platform_exit:
i8042_platform_exit();
return err;
+#endif
}
static void __exit i8042_exit(void)
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] i8042: Add OF match table
The OF device table allows the platform_driver_probe() function to
automatically match device and parse the DT node.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
Signed-off-by: Roman Volkov v1...@v1ros.org
---
drivers/input/serio/i8042.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 986a71c..2f09062 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -1474,12 +1474,22 @@ static int i8042_remove(struct platform_device *dev)
return 0;
}
+#ifdef SERIO_I8042_DT
+static struct of_device_id i8042_dt_ids[] = {
+ { .compatible = intel,8042 },
+ { /* Sentinel */ },
+};
+#endif
+
static struct platform_driver i8042_driver = {
.driver = {
.name = i8042,
#ifdef CONFIG_PM
.pm = i8042_pm_ops,
#endif
+#ifdef SERIO_I8042_DT
+ .of_match_table = i8042_dt_ids,
+#endif
},
.remove = i8042_remove,
.shutdown = i8042_shutdown,
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] Device Tree support for i8042 driver
Yes, some embedded devices still use the i8042 controller. This patch set enables the i8042 driver to get necessary information from Device Tree instead of using specific headers with hardcoded addresses for each specific machine. For example, vt8500 architecture has i8042. v2: Changes in the documentation. Errors fixed in the initialization funtion. Redundant parameters removed from Device Tree bindings (init-reset, etc.). Roman Volkov (5): i8042: intel-8042 DT documentation i8042: Kernel configuration handling for DT support i8042: Add OF match table i8042: Prepare i8042 driver for DT support i8042: Add i8042_dt.h glue for DT support .../devicetree/bindings/input/intel-8042.txt | 26 ++ drivers/input/serio/i8042-dt.h | 104 + drivers/input/serio/i8042.c| 43 - drivers/input/serio/i8042.h| 3 + 4 files changed, 173 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/intel-8042.txt create mode 100644 drivers/input/serio/i8042-dt.h -- Friday the 13-th 2.3.0 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [tpmdd-devel] [PATCH] Added Little Endian support to vtpm module
Looks good to me.
Reviewed-by: Ashley Lai ash...@ahsleylai.com
Thanks,
--Ashley
On Thu, 12 Feb 2015, honclo wrote:
The tpm_ibmvtpm module is affected by an unaligned access problem.
ibmvtpm_crq_get_version failed with rc=-4 during boot when vTPM is
enabled in Power partition, which supports both little endian and
big endian modes.
We added little endian support to fix this problem:
1) added cpu_to_be64 calls to ensure BE data is sent from an LE OS.
2) added be16_to_cpu and be32_to_cpu calls to make sure data received
is in LE format on a LE OS.
Signed-off-by: Hon Ching(Vicky) Lo hon...@linux.vnet.ibm.com
Signed-off-by: Joy Latten jmlat...@linux.vnet.ibm.com
---
drivers/char/tpm/tpm_ibmvtpm.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c
b/drivers/char/tpm/tpm_ibmvtpm.c
index af74c57..1632242 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -148,7 +148,8 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip,
u8 *buf, size_t count)
crq.len = (u16)count;
crq.data = ibmvtpm-rtce_dma_handle;
- rc = ibmvtpm_send_crq(ibmvtpm-vdev, word[0], word[1]);
+ rc = ibmvtpm_send_crq(ibmvtpm-vdev, cpu_to_be64(word[0]),
+ cpu_to_be64(word[1]));
if (rc != H_SUCCESS) {
dev_err(ibmvtpm-dev, tpm_ibmvtpm_send failed rc=%d\n, rc);
rc = 0;
@@ -186,7 +187,8 @@ static int ibmvtpm_crq_get_rtce_size(struct
ibmvtpm_dev *ibmvtpm)
crq.valid = (u8)IBMVTPM_VALID_CMD;
crq.msg = (u8)VTPM_GET_RTCE_BUFFER_SIZE;
- rc = ibmvtpm_send_crq(ibmvtpm-vdev, buf[0], buf[1]);
+ rc = ibmvtpm_send_crq(ibmvtpm-vdev, cpu_to_be64(buf[0]),
+ cpu_to_be64(buf[1]));
if (rc != H_SUCCESS)
dev_err(ibmvtpm-dev,
ibmvtpm_crq_get_rtce_size failed rc=%d\n, rc);
@@ -212,7 +214,8 @@ static int ibmvtpm_crq_get_version(struct
ibmvtpm_dev *ibmvtpm)
crq.valid = (u8)IBMVTPM_VALID_CMD;
crq.msg = (u8)VTPM_GET_VERSION;
- rc = ibmvtpm_send_crq(ibmvtpm-vdev, buf[0], buf[1]);
+ rc = ibmvtpm_send_crq(ibmvtpm-vdev, cpu_to_be64(buf[0]),
+ cpu_to_be64(buf[1]));
if (rc != H_SUCCESS)
dev_err(ibmvtpm-dev,
ibmvtpm_crq_get_version failed rc=%d\n, rc);
@@ -327,7 +330,8 @@ static int tpm_ibmvtpm_suspend(struct device *dev)
crq.valid = (u8)IBMVTPM_VALID_CMD;
crq.msg = (u8)VTPM_PREPARE_TO_SUSPEND;
- rc = ibmvtpm_send_crq(ibmvtpm-vdev, buf[0], buf[1]);
+ rc = ibmvtpm_send_crq(ibmvtpm-vdev, cpu_to_be64(buf[0]),
+ cpu_to_be64(buf[1]));
if (rc != H_SUCCESS)
dev_err(ibmvtpm-dev,
tpm_ibmvtpm_suspend failed rc=%d\n, rc);
@@ -472,11 +476,11 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq
*crq,
case IBMVTPM_VALID_CMD:
switch (crq-msg) {
case VTPM_GET_RTCE_BUFFER_SIZE_RES:
- if (crq-len = 0) {
+ if (be16_to_cpu(crq-len) = 0) {
dev_err(ibmvtpm-dev, Invalid rtce size\n);
return;
}
- ibmvtpm-rtce_size = crq-len;
+ ibmvtpm-rtce_size = be16_to_cpu(crq-len);
ibmvtpm-rtce_buf = kmalloc(ibmvtpm-rtce_size,
GFP_KERNEL);
if (!ibmvtpm-rtce_buf) {
@@ -497,11 +501,11 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq
*crq,
return;
case VTPM_GET_VERSION_RES:
- ibmvtpm-vtpm_version = crq-data;
+ ibmvtpm-vtpm_version = be32_to_cpu(crq-data);
return;
case VTPM_TPM_COMMAND_RES:
/* len of the data in rtce buffer */
- ibmvtpm-res_len = crq-len;
+ ibmvtpm-res_len = be16_to_cpu(crq-len);
wake_up_interruptible(ibmvtpm-wq);
return;
default:
--
1.7.1
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
tpmdd-devel mailing list
tpmdd-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a
Re: [PATCH] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes
On Thu, Jan 29, 2015 at 05:51:06PM -0800, Bjorn Andersson wrote:
Add the regulator subnodes to the Qualcomm RPM MFD device tree bindings.
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
#include dt-bindings/mfd/qcom-rpm.h
@@ -66,5 +237,18 @@ frequencies.
#address-cells = 1;
#size-cells = 0;
+
+ pm8921_smps1: pm8921-smps1 {
+ compatible = qcom,rpm-pm8921-smps;
+ reg = QCOM_RPM_PM8921_SMPS1;
+
+ regulator-min-microvolt = 1225000;
+ regulator-max-microvolt = 1225000;
+ regulator-always-on;
+
+ bias-pull-down;
+
+ qcom,switch-mode-frequency = 320;
+ };
};
My only comment here is that most (all but one) of the other mfd regulator
devices use regulators {}. Still wonder if that's what we should do.
Otherwise,
Reviewed-by: Andy Gross agr...@codeaurora.org
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line 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] clk: Add PWM clock driver
Hi Thierry,
thank you for the comments.
Am Donnerstag, den 12.02.2015, 23:29 +0100 schrieb Thierry Reding:
On Fri, Dec 12, 2014 at 11:47:49AM +0100, Philipp Zabel wrote:
Some board designers, when running out of clock output pads, decide to
(mis)use PWM output pads to provide a clock to external components.
This driver supports this practice by providing an adapter between the
PWM and clock bindings in the device tree. As the PWM bindings specify
the period in the device tree, this is a fixed clock.
Typically the period is specified in DT because it is a board-level
characteristic. In this case where you emulate a clock using the PWM
channel you could simply ignore the period. After all you can freely
choose it during pwm_config() irrespective of the period specified in
DT.
The problem with with dynamic rate changes is that they go through the
PWM API, and due to rounding issues it is often impossible to obtain the
correct clock rate or upper and lower limits of the clock without
knowledge about the reference clock of the PWM itself, for example.
Other than that looks mostly good to me, just a few nits below.
[...]
diff --git a/Documentation/devicetree/bindings/clock/pwm-clock.txt
b/Documentation/devicetree/bindings/clock/pwm-clock.txt
new file mode 100644
index 000..751fff5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/pwm-clock.txt
@@ -0,0 +1,26 @@
+Binding for an external clock signal driven by a PWM pin.
+
+This binding uses the common clock binding[1] and the common PWM
binding[2].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/pwm/pwm.txt
+
+Required properties:
+- compatible : shall be pwm-clock.
+- #clock-cells : from common clock binding; shall be set to 0.
+- pwms : from common PWM binding; this determines the clock frequency
+ via the PWM period given in the pwm-specifier.
Perhaps: the period given in the PWM specifier?
Yes, I'll change that.
+Optional properties:
+- clock-output-names : From common clock binding.
+- clock-frequency : Exact output frequency, in case the pwm period
PWM period
Ok.
+ is not exact but was rounded to nanoseconds.
Does this make sense?
The PWM binding specifies the period value, but it is not good enough
for pwm-clock's purpose. Due to the rounding issue:
For the Nitrogen6X board I want to produce a 22 MHz 'clock' from a PWM
with 66 MHz reference clock, with a 33% duty cycle.
The period time for this rate is 45.4545 ns, but in the PWM bindings it
is only possible to request 45 ns or 46 ns and hope the PWM driver will
round into the right direction.
For one it's now easy to specify two different
values for the frequency, one using the PWM specifier, the other with
clock-frequency.
I agree this is suboptimal. At least there is a warning for this case.
According to the above, clock-frequency takes
precedence, but in that case, what use is there in having the PWM
specifier?
Are you suggesting the period given int the PWM specifier should be set
to 0?
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 455fd17..36a6918a 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -129,6 +129,13 @@ config COMMON_CLK_PALMAS
This driver supports TI Palmas devices 32KHz output KG and KG_AUDIO
using common clock framework.
+config COMMON_CLK_PWM
+ bool Clock driver for PWMs used as clock outputs
+ depends on PWM
+ ---help---
+ Adapter driver so that any PWM output can be (mis)used as clock signal
+ at 50% duty cycle.
Any reason why this isn't tristate?
No, I'll change that.
[...]
+#define to_clk_pwm(_hw) container_of(_hw, struct clk_pwm, hw)
Perhaps use a static inline so you get proper type checking?
Ok.
[...]
+ pwm = devm_pwm_get(pdev-dev, NULL);
+ if (IS_ERR(pwm))
+ return PTR_ERR(pwm);
+
+ if (!pwm || !pwm-period) {
I don't think there's a case where pwm can be NULL here.
I think you are right.
+ dev_err(pdev-dev, invalid pwm period\n);
PWM
Ok.
[...]
+ if (pwm-period != NSEC_PER_SEC / clk_pwm-fixed_rate
+ pwm-period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm-fixed_rate)) {
+ dev_err(pdev-dev,
+ clock-frequency does not match pwm period\n);
PWM
+static struct platform_driver clk_pwm_driver = {
+ .probe = clk_pwm_probe,
+ .remove = clk_pwm_remove,
+ .driver = {
+ .name = pwm-clock,
+ .of_match_table = of_match_ptr(clk_pwm_dt_ids),
+ },
+};
+
+module_platform_driver(clk_pwm_driver);
This is missing MODULE_AUTHOR, MODULE_DESCRIPTION and MODULE_LICENSE.
Will add them in the next round.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [Patch] ASoC: codec: Add missing deps/hdrs to MAX98357A
On Thu, Feb 12, 2015 at 02:35:54AM -0800, Kenneth Westfield wrote: From: Kenneth Westfield kwest...@codeaurora.org For the max98357a codec driver: - Add missing build dependancy to GPIOLIB in Kconfig. - Add header files to avoid implicit declarations and indirect inclusions. - Remove use of DRV_NAME constant. Several of these fixes have already been submitted by other people and applied and (as covered in SubmttingPatches) each you should submit one patch per logical change. Your changelog clearly identifies at least three different changes. signature.asc Description: Digital signature
Re: [alsa-devel] [Patch V4 00/10] ASoC: QCOM: Add support for ipq806x SOC
On Wed, Feb 11, 2015 at 11:20:33PM -0800, Patrick Lai wrote: On 2/11/2015 6:53 PM, Mark Brown wrote: On Wed, Feb 11, 2015 at 05:05:52PM -0800, Kenneth Westfield wrote: Replacing DSP-based drivers with LPASS-based drivers would be something that should be handled by Kconfig selections. For the DT, the DSP-related No, it shouldn't be. We should have the ability to build a single kernel image which will run on many systems, including both your system with a DSP and other systems without. Is there expectation that DTB flashed onto the system would define nodes to bind with both LPASS-based driver and DSP-based driver? I hope not as we want to keep LPASS-based driver DSP-based driver mutually exclusive. DTB time selections are a separate thing to Kconfig changes like Kenneth was proposing. They're more viable though it'd be a lot better to avoid needing them, designing out the possibility of doing something is often a sure fire way of finding a user. The selection of DSP use sounds like something which isn't part of the description of the hardware but rather a runtime policy decision (at least in so far as non-DSP is ever an option). Put aside IPQ8064, I would say it is actually more of build time policy decision for QC SoCs with DSP. XPU is programmed by trust zone to allow certain LPASS registers to be accessed by the chosen processor. If ADSP and app processor would have to have access to audio interfaces and DMA, resources partition(i.e # of DMAs go to ADSP while rest of DMA go to app processor is decided after analyzing expected concurrency use case. For case of 8016, MDSP would simply expect it has access to all audio subsystem except digital core of CODEC. But is it possible to configure the TrustZone firmware to leave things open? That's the tricky case. Actually, can we read the configuration TrustZone did? That might be the best answer here, the DT can describe the silicon and then we can check at runtime which bits of it we're actually allowed to talk to. signature.asc Description: Digital signature
