Re: [PATCH 09/21] drm/omap: handle mismatching color format and buffer width
On Thu, Feb 26, 2015 at 03:20:17PM +0200, Tomi Valkeinen wrote:
omapdrm doesn't check if the width of the framebuffer and the color
format's bits-per-pixel match.
For example, using a display with a width of 1280, and a buffer
allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with
a 24 bits per pixel color format, leads to the following mismatch:
5120/3 = 1706.666... bytes. This causes bad colors and a tilt on the
screen.
Add a check into omapdrm to return an error if the user tries to use
such a combination.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_fb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 2975096abdf5..bf98580223d0 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -463,6 +463,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct
drm_device *dev,
goto fail;
}
+ if (mode_cmd-width % format-planes[i].stride_bpp != 0) {
width is in pixels. No idea what you're trying to check here, but this
probably isn't it.
Also drm checks that things fit into the specified pitch (which is in
bytes), see the pichtes[i] width * cpp check in framebuffer_check.
Cheers, Daniel
+ dev_err(dev-dev,
+ buffer width (%d) is not a multiple of pixel
width (%d)\n,
+ mode_cmd-width, format-planes[i].stride_bpp);
+ ret = -EINVAL;
+ goto fail;
+ }
+
size = pitch * mode_cmd-height / format-planes[i].sub_y;
if (size (omap_gem_mmap_size(bos[i]) - mode_cmd-offsets[i]))
{
--
2.3.0
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] soc: ti: Add wkup_m3_ipc driver
Tony, On 02/26/2015 04:08 PM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [150226 12:05]: Tony, On 01/05/2015 04:51 PM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [150105 14:51]: Felipe, On 01/02/2015 02:16 PM, Felipe Balbi wrote: On Fri, Jan 02, 2015 at 02:00:16PM -0600, Dave Gerlach wrote: Introduce a wkup_m3_ipc driver to handle communication between the MPU and Cortex M3 wkup_m3 present on am335x. This driver is responsible for actually booting the wkup_m3_rproc and also handling all IPC which is done using the IPC registers in the control module, a mailbox, and a separate interrupt back from the wkup_m3. A small API is exposed for executing specific power commands, which include configuring for low power mode, request a transition to a low power mode, and status info on a previous transition. Signed-off-by: Dave Gerlach d-gerl...@ti.com --- drivers/soc/ti/Kconfig | 11 ++ drivers/soc/ti/Makefile | 1 + drivers/soc/ti/wkup_m3_ipc.c | 451 +++ include/linux/wkup_m3_ipc.h | 33 4 files changed, 496 insertions(+) create mode 100644 drivers/soc/ti/wkup_m3_ipc.c create mode 100644 include/linux/wkup_m3_ipc.h diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig index 7266b21..61cda85 100644 --- a/drivers/soc/ti/Kconfig +++ b/drivers/soc/ti/Kconfig @@ -28,4 +28,15 @@ config KEYSTONE_NAVIGATOR_DMA If unsure, say N. +config WKUP_M3_IPC +bool TI AM33XX Wkup-M3 IPC Driver tristate ? If we want to allow this and the rproc driver to be built as modules than we can change this. Yes please, the PM is never needed early, and should be optional. And doing that will make it a lot easier for you to do further work on your driver ;) And it will also make it easier to add support for other SoCs as it seems the same M3 is used at least on am437x. I can not build the PM code as a module at this time due to many mach-omap function calls it uses which are not exported, so I need handles to all five functions in this driver used in pm33xx to call from built-in PM code. Do you have a preference on how these function handles get passed? OK, you can pass the function pointers in platform_data. Care to list those functions? That might allow us to make other omap PM code into loadable modules in drivers/* :) Sure, apart from the dependencies I create for myself in other modules that I introduce I see: ERROR: omap_pm_clkdms_setup [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: clkdm_for_each [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: clkdm_lookup [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: pwrdm_lookup [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: pwrdm_post_transition [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: clkdm_sleep [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: clkdm_wakeup [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: pwrdm_read_pwrst [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: cpu_suspend [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: omap_set_pwrdm_state [arch/arm/mach-omap2/pm33xx.ko] undefined! So the mach-omap2 clockdomain and power domain functions along with arch arm cpu_suspend code. I see similar dependencies in the other mach-omap2/pm.c code also. I currently have added a pdata-quirks implementation that passes a function to the wkup_m3_ipc driver through it's pdata which it then calls at probe to pass a struct containing all used function pointers to the pm code that were previously called directly. Is that what you would prefer or something else? I had also looked at making the struct of function pointers in the driver global and just picking it up from the pm code with an extern declaration or even putting a bus notifier in the PM code and watching for the wkup_m3_ipc driver to be bound. Yeah pdata-quirks.c is probably OK for populating the function pointers. We may have already some place in the PM code to pass it too. Alright, thanks for your input. Thought I would see what you prefer and possibly avoid an unnecessary re-spin. Sounds like we're getting close to getting am335x/am437x PM code working :) Getting there! Regards, Dave Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] soc: ti: Add wkup_m3_ipc driver
* Dave Gerlach d-gerl...@ti.com [150227 09:04]: Tony, On 02/26/2015 04:08 PM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [150226 12:05]: Tony, On 01/05/2015 04:51 PM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [150105 14:51]: Felipe, On 01/02/2015 02:16 PM, Felipe Balbi wrote: On Fri, Jan 02, 2015 at 02:00:16PM -0600, Dave Gerlach wrote: Introduce a wkup_m3_ipc driver to handle communication between the MPU and Cortex M3 wkup_m3 present on am335x. This driver is responsible for actually booting the wkup_m3_rproc and also handling all IPC which is done using the IPC registers in the control module, a mailbox, and a separate interrupt back from the wkup_m3. A small API is exposed for executing specific power commands, which include configuring for low power mode, request a transition to a low power mode, and status info on a previous transition. Signed-off-by: Dave Gerlach d-gerl...@ti.com --- drivers/soc/ti/Kconfig | 11 ++ drivers/soc/ti/Makefile | 1 + drivers/soc/ti/wkup_m3_ipc.c | 451 +++ include/linux/wkup_m3_ipc.h | 33 4 files changed, 496 insertions(+) create mode 100644 drivers/soc/ti/wkup_m3_ipc.c create mode 100644 include/linux/wkup_m3_ipc.h diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig index 7266b21..61cda85 100644 --- a/drivers/soc/ti/Kconfig +++ b/drivers/soc/ti/Kconfig @@ -28,4 +28,15 @@ config KEYSTONE_NAVIGATOR_DMA If unsure, say N. +config WKUP_M3_IPC + bool TI AM33XX Wkup-M3 IPC Driver tristate ? If we want to allow this and the rproc driver to be built as modules than we can change this. Yes please, the PM is never needed early, and should be optional. And doing that will make it a lot easier for you to do further work on your driver ;) And it will also make it easier to add support for other SoCs as it seems the same M3 is used at least on am437x. I can not build the PM code as a module at this time due to many mach-omap function calls it uses which are not exported, so I need handles to all five functions in this driver used in pm33xx to call from built-in PM code. Do you have a preference on how these function handles get passed? OK, you can pass the function pointers in platform_data. Care to list those functions? That might allow us to make other omap PM code into loadable modules in drivers/* :) Sure, apart from the dependencies I create for myself in other modules that I introduce I see: ERROR: omap_pm_clkdms_setup [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: clkdm_for_each [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: clkdm_lookup [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: pwrdm_lookup [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: pwrdm_post_transition [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: clkdm_sleep [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: clkdm_wakeup [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: pwrdm_read_pwrst [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: cpu_suspend [arch/arm/mach-omap2/pm33xx.ko] undefined! ERROR: omap_set_pwrdm_state [arch/arm/mach-omap2/pm33xx.ko] undefined! So the mach-omap2 clockdomain and power domain functions along with arch arm cpu_suspend code. I see similar dependencies in the other mach-omap2/pm.c code also. OK thanks for the list. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] ARM: dts: n9/n950: Enable omap crypto support
* Pali Rohár pali.ro...@gmail.com [150227 08:05]: On Friday 27 February 2015 16:43:20 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150226 05:54]: Harmattan system on Nokia N9 and N950 devices uses omap crypto support. Bootloader on those devices is known that it enables HW crypto support. This patch just include omap36xx.dtsi directly, so aes and sham is enabled. Let's also remove omap36xx-hs.dtsi with this patch if no other users. Removing both -hs files is done by last patch in this series. Yes just noticed thanks, no need to change. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS
Hello. On 2/27/2015 5:17 PM, Robert Abel wrote: Documentation/kernel-doc-nano-HOWTO.txt requires colons after the parameter names, doesn't it? Jesus Christ, you guys are killing me... I've already spent way more time on this patch series than I intended to anyway... That's what you get when pushing your stuff upstream. You're not alone here. :-) + mask = (1 nr_bits) - 1; BIT(nr_bits) - 1, perhaps? Not happening... BIT macro obscures what's actually going on. I did search for a macro that does ((1 n) - 1) but didn't found it, unfortunately... Regards, Robert WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS
Hi Roger, On Fri, Feb 27, 2015 at 11:43 AM, Roger Quadros rog...@ti.com wrote: time_ns_min = gpmc_ticks_to_ns(l ? l - 1 : 0); should be time_ns_min = l ? gpmc_ticks_to_ns(l - 1) + 1 : 0; That's a micro-optimization. + 1ns since we don't want to fall into the previous tick bracket. for l == 0 we have t_min as 0. no need to pass it through gpmc_ticks_to_ns() or add 1 ns. That's why the invervals are half-open. I can make them closed, no problem. Regards, Robert -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS
On Thu, Feb 26, 2015 at 4:06 PM, Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote: Documentation/kernel-doc-nano-HOWTO.txt requires colons after the parameter names, doesn't it? Jesus Christ, you guys are killing me... I've already spent way more time on this patch series than I intended to anyway... + mask = (1 nr_bits) - 1; BIT(nr_bits) - 1, perhaps? Not happening... BIT macro obscures what's actually going on. Regards, Robert -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/21] drm/omap: handle mismatching color format and buffer width
Hi,
On 27 February 2015 at 13:01, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Feb 26, 2015 at 03:20:17PM +0200, Tomi Valkeinen wrote:
omapdrm doesn't check if the width of the framebuffer and the color
s/width/pitch/
format's bits-per-pixel match.
s/match/are compatible/
For example, using a display with a width of 1280, and a buffer
allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with
Might be clearer to say 'i.e. byte stride of ...', and also s/with using/for/.
a 24 bits per pixel color format, leads to the following mismatch:
5120/3 = 1706.666... bytes. This causes bad colors and a tilt on the
s/bytes/pixels/
screen.
Add a check into omapdrm to return an error if the user tries to use
such a combination.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_fb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 2975096abdf5..bf98580223d0 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -463,6 +463,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct
drm_device *dev,
goto fail;
}
+ if (mode_cmd-width % format-planes[i].stride_bpp != 0) {
width is in pixels. No idea what you're trying to check here, but this
probably isn't it.
stride_bpp is very misnamed: it is the bits per pixel for that plane,
and not stride at all. I think the check should in fact be be (pitch %
format-planes[i].stride_bpp), which would achieve the desired result,
i.e. that the stride can be expressed as an integer number of pixels.
Also drm checks that things fit into the specified pitch (which is in
bytes), see the pichtes[i] width * cpp check in framebuffer_check.
This isn't that check. At some stages, OMAP IIRC requires pitch to be
specified in pixels rather than bytes, so this makes sure that's
possible to express.
Cheers,
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] omap3 crypto fixes
On Thursday 26 February 2015 23:46:05 Aaro Koskinen wrote: Hi, On Thu, Feb 26, 2015 at 02:49:50PM +0100, Pali Rohár wrote: This patch series fix crypto support for omap3 devices which use DT. It enables AES and SHAM on N9/N950 and SHAM on N900. AES is still disabled for N900. (Please format your lines somewhere near 76 chars, especially in commit logs, otherwise git log looks ugly on 80 char terminals.) I tested these with stock bootloaders, and devices boot normally and I can now modprobe omap-aes (on N9 and N950) and omap-sham (on all three): omap-aes 480c5000.aes: OMAP AES hw accel rev: 2.6 omap-sham 480c3000.sham: hw accel on OMAP rev 0.9 However I get these when CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set: alg: hash: Chunking test 1 failed for omap-sha1 alg: hash: Chunking test 1 failed for omap-md5 alg: hash: Chunking test 1 failed for omap-hmac-sha1 alg: hash: Chunking test 1 failed for omap-hmac-md5 But that's probably unrelated to this series. For patches 1-8, feel free to add: Tested-by: Aaro Koskinen aaro.koski...@iki.fi A. Hi, thanks for testing! Now I'm happy that I can load omap-aes and omap-sham drivers on real n900 device, qemu n900 and after your tests also on real n9 and n950 without any kernel crash or oops. Of course omap-aes is disabled on n900, but loading omap-aes.ko (accidentally) does not hurt. It looks like there are other parts in md5 and sha broken, but first step is load register all drivers without kernel crash. And this is working now. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
[PATCH] ARM: OMAP4+: PRM: fix omap4 version of prm_save_and_clear_irqen
This was incorrectly reading the irq status registers during the save
and clear, instead of the irq enable. This worked because there is only
one user for the prcm interrupts currently, namely the io-chain. Whenever
the function was called, an io-chain interrupt was both pending and
enabled.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/prm44xx.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index a08a617..d6d6bc3 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -252,10 +252,10 @@ static void omap44xx_prm_save_and_clear_irqen(u32
*saved_mask)
{
saved_mask[0] =
omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
- OMAP4_PRM_IRQSTATUS_MPU_OFFSET);
+ OMAP4_PRM_IRQENABLE_MPU_OFFSET);
saved_mask[1] =
omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
- OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET);
+ OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
omap4_prm_write_inst_reg(0, OMAP4430_PRM_OCP_SOCKET_INST,
OMAP4_PRM_IRQENABLE_MPU_OFFSET);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: OMAP5: fix polling intervals for thermal zones
OMAP4 has a finer counter granularity, which allows for a delay of 1000ms
in the thermal zone polling intervals. OMAP5 has a different counter
mechanism, which allows at maximum a 500ms timer. Adjust the cpu thermal
zone polling interval accordingly.
Without this patch, the polling interval information is simply ignored,
and the following thermal warnings are printed during boot (assuming
thermal is enabled);
[1.545343] ti-soc-thermal 4a0021e0.bandgap: Delay 1000 ms is not supported
[1.552691] ti-soc-thermal 4a0021e0.bandgap: Delay 1000 ms is not supported
[1.560029] ti-soc-thermal 4a0021e0.bandgap: Delay 1000 ms is not supported
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap5-core-thermal.dtsi |2 +-
arch/arm/boot/dts/omap5-gpu-thermal.dtsi |2 +-
arch/arm/boot/dts/omap5.dtsi |4
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-core-thermal.dtsi
b/arch/arm/boot/dts/omap5-core-thermal.dtsi
index 19212ac..de8a3d4 100644
--- a/arch/arm/boot/dts/omap5-core-thermal.dtsi
+++ b/arch/arm/boot/dts/omap5-core-thermal.dtsi
@@ -13,7 +13,7 @@
core_thermal: core_thermal {
polling-delay-passive = 250; /* milliseconds */
- polling-delay = 1000; /* milliseconds */
+ polling-delay = 500; /* milliseconds */
/* sensor ID */
thermal-sensors = bandgap 2;
diff --git a/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
index 1b87aca..bc3090f 100644
--- a/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
+++ b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
@@ -13,7 +13,7 @@
gpu_thermal: gpu_thermal {
polling-delay-passive = 250; /* milliseconds */
- polling-delay = 1000; /* milliseconds */
+ polling-delay = 500; /* milliseconds */
/* sensor ID */
thermal-sensors = bandgap 1;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b321fdf..fee1580 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -1079,4 +1079,8 @@
};
};
+cpu_thermal {
+ polling-delay = 500; /* milliseconds */
+};
+
/include/ omap54xx-clocks.dtsi
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.20-rc0 breaks nfsroot over usb
* Aaro Koskinen aaro.koski...@iki.fi [150226 15:06]: Hi, On Thu, Feb 26, 2015 at 11:19:50PM +0100, Pavel Machek wrote: Ok, it seems that new config dependencies broke my kconfig. These will not be enabled if you just to make oldconfig; you want to make sure they are on. OMAP2430 and onwards (USB_MUSB_OMAP2PLUS) [N/m/y] (NEW) TWL4030 USB Transceiver Driver (TWL4030_USB) [N/m/y/?] (NEW) Yes, also other users have reported USB breakage with 4.0-rc1 on N900 etc caused by this. Commit fbba7db3990cb707ff91cd6507d53a0a730afe97 (usb: musb: add omap-control dependency) changed USB_MUSB_OMAP2PLUS to depend on OMAP_CONTROL_PHY but that seems to be wrong at least for OMAP3. omap_control_phy.h provides dummy functions when it's not enabled. So there should be no dependency. I guess the solution would be to make drivers/phy handle whatever omap_control_usb_set_mode is doing in a generic way. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] ARM: dts: n9/n950: Enable omap crypto support
On Friday 27 February 2015 16:43:20 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150226 05:54]: Harmattan system on Nokia N9 and N950 devices uses omap crypto support. Bootloader on those devices is known that it enables HW crypto support. This patch just include omap36xx.dtsi directly, so aes and sham is enabled. Let's also remove omap36xx-hs.dtsi with this patch if no other users. Removing both -hs files is done by last patch in this series. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 07/10] ARM: dts: n9/n950: Enable omap crypto support
* Pali Rohár pali.ro...@gmail.com [150226 05:54]:
Harmattan system on Nokia N9 and N950 devices uses omap crypto support.
Bootloader on those devices is known that it enables HW crypto support.
This patch just include omap36xx.dtsi directly, so aes and sham is enabled.
Let's also remove omap36xx-hs.dtsi with this patch if no other users.
Regards,
Tony
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/boot/dts/omap3-n950-n9.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index c41db94..800b379 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -8,7 +8,7 @@
* published by the Free Software Foundation.
*/
-#include omap36xx-hs.dtsi
+#include omap36xx.dtsi
/ {
cpus {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS
* Sergei Shtylyov sergei.shtyl...@cogentembedded.com [150227 06:27]: Hello. On 2/27/2015 5:17 PM, Robert Abel wrote: Documentation/kernel-doc-nano-HOWTO.txt requires colons after the parameter names, doesn't it? Jesus Christ, you guys are killing me... I've already spent way more time on this patch series than I intended to anyway... That's what you get when pushing your stuff upstream. You're not alone here. :-) And thanks for the effort. Best to fix up things for good, that will save headaches later on for everybody. Hmm did you file all the forms for a change request in the kernel? Just kidding :) Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] ARM OMAP2+ GPMC: add bus children
Hi Roger, On Fri, Feb 27, 2015 at 11:24 AM, Roger Quadros rog...@ti.com wrote: + /* is child a common bus? */ + if (of_match_node(of_default_bus_match_table, child)) + /* create children and other common bus children */ + if (of_platform_populate(child, of_default_bus_match_table, NULL, pdev-dev)) + goto err_child_fail; this would print failed to create gpmc child but we have already created the gpmc child in the first of_platform_device_create() call. A more appropriate message would be failed to populate all children of child-name Also do you want to return failure? it will result in of_node_put() of the child and another print message about probing gpmc child %s failed in gpmc_probe_dt(). IMO if the GPMC node's child was created fine then we shouldn't return error. As of_platform_populate _always_ return 0 no matter what, the only way to reach that message is if probing the child failed. As I cannot see into the future when of_platform_populate might actually be changed to return meaningful codes, we shouldn't try to foresee what the actual problem might be today either. This is a battle for another day. Regards, Robert -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8 v4] ARM OMAP2+ GPMC: fixes and bus children
These are the changes I proposed in these patch series: [1], [2], [3], [4] rebased to 3.19 as well as new changes for little bugs I noticed while preparing this patch series as well as changes introduced via comments. 1. DEBUG was undefined in source code -- remove offending lines 2. add capability to have busses as children of the GPMC and multiple devices on a bus. See [2] for an example DTS syntax. 3. debug output was unaligned -- align it 4. output for copy-pasting to DTS had erroneous timing outputs and made it hard to copy-paste -- correct timing values, add comments as DTS comments. 5. WAITMONITORINGTIME is expressed as GPMC_CLK cycles for all accesses. GPMCFCLKDIVIDER is used as a divider, so it must always be programmed. 6. GPMCFCLKDIVIDER is calculated according to WAITMONITORINGTIME for asynchronous accesses inside the driver -- asynchronous accesses now completely decoupled from gpmc,sync-clk-ps. 7. WAITMONITORINGTIME was being programmed/shown in GPMC_FCLK cycles instead of GPMC_CLK cycles -- add clock domain information where necessary. 8. Calculated values for WAITMONITORINGTIME and CLKACTIVATIONTIME that were outside the defined range would not raise an error. DEVICESIZE, ATTACHEDDEVICEPAGELENGTH, WAITMONITORINGTIME and CLKACTIVATIONTIME would not be marked as incorrect on DTS output. -- Fix all of these. [1]: https://lkml.org/lkml/2015/2/12/495 [2]: https://lkml.org/lkml/2015/2/16/337 [3]: https://lkml.org/lkml/2015/2/24/609 [4]: https://lkml.org/lkml/2015/2/26/387 Robert ABEL (9): ARM OMAP2+ GPMC: don't undef DEBUG ARM OMAP2+ GPMC: add bus children ARM OMAP2+ GPMC: fix debug output alignment ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER ARM OMAP2+ GPMC: calculate GPMCFCLKDIVIDER based on WAITMONITORINGTIME ARM OMAP2+ GPMC: fix WAITMONITORINGTIME divider bug ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters arch/arm/mach-omap2/gpmc-nand.c| 17 +- arch/arm/mach-omap2/gpmc-onenand.c | 4 +- arch/arm/mach-omap2/usb-tusb6010.c | 4 +- drivers/memory/Makefile| 2 + drivers/memory/omap-gpmc.c | 313 + include/linux/omap-gpmc.h | 2 +- 6 files changed, 265 insertions(+), 77 deletions(-) -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8 v4] ARM OMAP2+ GPMC: don't undef DEBUG
OMAP2+ GPMC driver undefines DEBUG, which makes it unnecessarily hard to turn DEBUG on. Remove the offending lines. Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de --- drivers/memory/omap-gpmc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c index 24696f5..5cabac8 100644 --- a/drivers/memory/omap-gpmc.c +++ b/drivers/memory/omap-gpmc.c @@ -12,8 +12,6 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ -#undef DEBUG - #include linux/irq.h #include linux/kernel.h #include linux/init.h -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/21] drm/omap: handle mismatching color format and buffer width
On Fri, Feb 27, 2015 at 02:40:20PM +, Daniel Stone wrote:
On 27 February 2015 at 13:01, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Feb 26, 2015 at 03:20:17PM +0200, Tomi Valkeinen wrote:
omapdrm doesn't check if the width of the framebuffer and the color
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 2975096abdf5..bf98580223d0 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -463,6 +463,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct
drm_device *dev,
goto fail;
}
+ if (mode_cmd-width % format-planes[i].stride_bpp != 0) {
width is in pixels. No idea what you're trying to check here, but this
probably isn't it.
stride_bpp is very misnamed: it is the bits per pixel for that plane,
and not stride at all. I think the check should in fact be be (pitch %
format-planes[i].stride_bpp), which would achieve the desired result,
i.e. that the stride can be expressed as an integer number of pixels.
I meant that mode_cmd-width is in pixels and so totally not what you want
to check here. It probably should be mode_cmd-pitches[i].
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8 v4] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS
DTS output was formatted to require additional work when copy-pasting into DTS.
Nano-second timings were replaced with interval of values that produce the same
number of clock ticks.
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
---
drivers/memory/omap-gpmc.c | 38 --
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index dbb6753..432e638 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -337,32 +337,50 @@ static void gpmc_cs_bool_timings(int cs, const struct
gpmc_bool_timings *p)
}
#ifdef DEBUG
+/**
+ * get_gpmc_timing_reg - read a timing parameter and print DTS settings for it.
+ * @cs: Chip Select Region
+ * @reg: GPMC_CS_CONFIGn register offset.
+ * @st_bit: Start Bit
+ * @end_bit: End Bit. Must be = @st_bit.
+ * @name:DTS node name, w/o gpmc,
+ * @raw: Raw Format Option.
+ * raw format: gpmc,name = value
+ * tick format: gpmc,name = value /zwj;* x ns -- y ns; x ticks
*zwj;/
+ * Where x ns -- y ns result in the same tick value.
+ * @noval: Parameter values equal to 0 are not printed.
+ * @shift: Parameter value left shifts @shift, which is then printed instead
of value.
+ * @return: Specified timing parameter (after optional @shift).
+ *
+ */
static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
bool raw, bool noval, int shift,
const char *name)
{
u32 l;
- int nr_bits, max_value, mask;
+ int nr_bits;
+ int mask;
l = gpmc_cs_read_reg(cs, reg);
nr_bits = end_bit - st_bit + 1;
- max_value = (1 nr_bits) - 1;
- mask = max_value st_bit;
- l = (l mask) st_bit;
+ mask = (1 nr_bits) - 1;
+ l = (l st_bit) mask;
if (shift)
l = (shift l);
if (noval (l == 0))
return 0;
if (!raw) {
- unsigned int time_ns_min, time_ns, time_ns_max;
+ /* DTS tick format for timings in ns */
+ unsigned int time_ns;
+ unsigned int time_ns_min = 0;
- time_ns_min = gpmc_ticks_to_ns(l ? l - 1 : 0);
+ if (l)
+ time_ns_min = gpmc_ticks_to_ns(l - 1) + 1;
time_ns = gpmc_ticks_to_ns(l);
- time_ns_max = gpmc_ticks_to_ns(l + 1 max_value ?
- max_value : l + 1);
- pr_info(gpmc,%s = %u (%u - %u ns, %i ticks)\n,
- name, time_ns, time_ns_min, time_ns_max, l);
+ pr_info(gpmc,%s = %u /* %u ns - %u ns; %i ticks */\n,
+ name, time_ns, time_ns_min, time_ns, l);
} else {
+ /* raw format */
pr_info(gpmc,%s = %u\n, name, l);
}
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8 v4] ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters
GPMC_CONFIG1_i parameters CLKACTIVATIONTIME and WAITMONITORINGTIME
have reserved values.
Raise an error if calculated timings try to program reserved values.
GPMC_CONFIG1_i ATTACHEDDEVICEPAGELENGTH and DEVICESIZE were already checked
when parsing the DT.
Explicitly comment invalid values on gpmc_cs_show_timings for
-CLKACTIVATIONTIME
-WAITMONITORINGTIME
-DEVICESIZE
-ATTACHEDDEVICEPAGELENGTH
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
---
drivers/memory/omap-gpmc.c | 68 ++
1 file changed, 45 insertions(+), 23 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index d091065..750c655 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -135,7 +135,11 @@
#define GPMC_CONFIG1_WRITETYPE_ASYNC(0 27)
#define GPMC_CONFIG1_WRITETYPE_SYNC (1 27)
#define GPMC_CONFIG1_CLKACTIVATIONTIME(val) ((val 3) 25)
+/** CLKACTIVATIONTIME Max Ticks */
+#define GPMC_CONFIG1_CLKACTIVATIONTIME_MAX 2
#define GPMC_CONFIG1_PAGE_LEN(val) ((val 3) 23)
+/** ATTACHEDDEVICEPAGELENGTH Max Value */
+#define GPMC_CONFIG1_ATTACHEDDEVICEPAGELENGTH_MAX 2
#define GPMC_CONFIG1_WAIT_READ_MON (1 22)
#define GPMC_CONFIG1_WAIT_WRITE_MON (1 21)
#define GPMC_CONFIG1_WAIT_MON_TIME(val) ((val 3) 18)
@@ -144,6 +148,8 @@
#define GPMC_CONFIG1_WAIT_PIN_SEL(val) ((val 3) 16)
#define GPMC_CONFIG1_DEVICESIZE(val)((val 3) 12)
#define GPMC_CONFIG1_DEVICESIZE_16 GPMC_CONFIG1_DEVICESIZE(1)
+/** DEVICESIZE Max Value */
+#define GPMC_CONFIG1_DEVICESIZE_MAX 1
#define GPMC_CONFIG1_DEVICETYPE(val)((val 3) 10)
#define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
#define GPMC_CONFIG1_MUXTYPE(val) ((val 3) 8)
@@ -393,6 +399,8 @@ static void gpmc_cs_bool_timings(int cs, const struct
gpmc_bool_timings *p)
* @reg: GPMC_CS_CONFIGn register offset.
* @st_bit: Start Bit
* @end_bit: End Bit. Must be = @st_bit.
+ * @ma:x Maximum parameter value (before optional @shift).
+ * If 0, maximum is as high as @st_bit and @end_bit allow.
* @name:DTS node name, w/o gpmc,
* @cd: Clock Domain of timing parameter.
* @shift: Parameter value left shifts @shift, which is then printed instead
of value.
@@ -400,13 +408,14 @@ static void gpmc_cs_bool_timings(int cs, const struct
gpmc_bool_timings *p)
* raw format: gpmc,name = value
* tick format: gpmc,name = value /zwj;* x ns -- y ns; x ticks
*zwj;/
* Where x ns -- y ns result in the same tick value.
+ * When @max is exceeded, invalid is printed inside comment.
* @noval: Parameter values equal to 0 are not printed.
* @return: Specified timing parameter (after optional @shift).
*
*/
static int get_gpmc_timing_reg(
/* timing specifiers */
- int cs, int reg, int st_bit, int end_bit,
+ int cs, int reg, int st_bit, int end_bit, int max,
const char *name, const enum gpmc_clk_domain cd,
/* value transform */
int shift,
@@ -416,11 +425,15 @@ static int get_gpmc_timing_reg(
u32 l;
int nr_bits;
int mask;
+ bool invalid;
l = gpmc_cs_read_reg(cs, reg);
nr_bits = end_bit - st_bit + 1;
mask = (1 nr_bits) - 1;
l = (l st_bit) mask;
+ if (!max)
+ max = mask;
+ invalid = l max;
if (shift)
l = (shift l);
if (noval (l == 0))
@@ -433,11 +446,11 @@ static int get_gpmc_timing_reg(
if (l)
time_ns_min = gpmc_clk_ticks_to_ns(l - 1, cs, cd) + 1;
time_ns = gpmc_clk_ticks_to_ns(l, cs, cd);
- pr_info(gpmc,%s = %u /* %u ns - %u ns; %i ticks */\n,
- name, time_ns, time_ns_min, time_ns, l);
+ pr_info(gpmc,%s = %u /* %u ns - %u ns; %i ticks%s*/\n,
+ name, time_ns, time_ns_min, time_ns, l, invalid ? ;
invalid : );
} else {
/* raw format */
- pr_info(gpmc,%s = %u\n, name, l);
+ pr_info(gpmc,%s = %u%s\n, name, l, invalid ? /* invalid
*/ : );
}
return l;
@@ -447,15 +460,19 @@ static int get_gpmc_timing_reg(
pr_info(cs%i %s: 0x%08x\n, cs, #config, \
gpmc_cs_read_reg(cs, config))
#define GPMC_GET_RAW(reg, st, end, field) \
- get_gpmc_timing_reg(cs, (reg), (st), (end), field, GPMC_CD_FCLK, 0, 1,
0)
+ get_gpmc_timing_reg(cs, (reg), (st), (end), 0, field, GPMC_CD_FCLK, 0,
1, 0)
+#define GPMC_GET_RAW_MAX(reg, st, end, max, field) \
+ get_gpmc_timing_reg(cs, (reg), (st), (end), (max), field, GPMC_CD_FCLK,
0, 1, 0)
#define GPMC_GET_RAW_BOOL(reg, st, end, field) \
- get_gpmc_timing_reg(cs, (reg), (st), (end), field, GPMC_CD_FCLK, 0, 1,
1)
-#define GPMC_GET_RAW_SHIFT(reg, st, end, shift, field) \
- get_gpmc_timing_reg(cs, (reg), (st), (end), field, GPMC_CD_FCLK,
[PATCH 5/8 v4] ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER
The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
even though the access is defined as asynchronous, and no GPMC_CLK clock
is provided to the external device. Still, GPMCFCLKDIVIDER is used as a divider
for the GPMC clock, so it must be programmed to define the
correct WAITMONITORINGTIME delay.
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
---
drivers/memory/omap-gpmc.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 432e638..02e5228 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -499,7 +499,7 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit,
int end_bit,
l = gpmc_cs_read_reg(cs, reg);
#ifdef DEBUG
- printk(KERN_INFO
+ pr_info(
GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n,
cs, name, ticks, gpmc_get_fclk_period() * ticks / 1000,
(l st_bit) mask, time);
@@ -571,19 +571,14 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
if (gpmc_capability GPMC_HAS_WR_ACCESS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
- /* caller is expected to have initialized CONFIG1 to cover
-* at least sync vs async
-*/
l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
- if (l (GPMC_CONFIG1_READTYPE_SYNC | GPMC_CONFIG1_WRITETYPE_SYNC)) {
#ifdef DEBUG
- printk(KERN_INFO GPMC CS%d CLK period is %lu ns (div %d)\n,
- cs, (div * gpmc_get_fclk_period()) / 1000, div);
+ pr_info(GPMC CS%d CLK period is %lu ns (div %d)\n,
+ cs, (div * gpmc_get_fclk_period()) / 1000, div);
#endif
- l = ~0x03;
- l |= (div - 1);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
- }
+ l = ~0x03;
+ l |= (div - 1);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
gpmc_cs_bool_timings(cs, t-bool_timings);
gpmc_cs_show_timings(cs, after gpmc_cs_set_timings);
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8 v4] ARM OMAP2+ GPMC: fix WAITMONITORINGTIME divider bug
The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
even though the access is defined as asynchronous, and no GPMC_CLK clock
is provided to the external device. Still, GPMCFCLKDIVIDER is used as a divider
for the GPMC clock, so it must be programmed to define the
correct WAITMONITORINGTIME delay.
This patch correctly computes WAITMONITORINGTIME in GPMC_CLK cycles instead of
GPMC_FCLK cycles,
both during programming (gpmc_cs_set_timings) and during retrieval
(gpmc_cs_show_timings).
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
---
drivers/memory/omap-gpmc.c | 128 +++--
1 file changed, 101 insertions(+), 27 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 8ee335d..d091065 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -170,6 +170,11 @@
*/
#defineGPMC_NR_IRQ 2
+enum gpmc_clk_domain {
+ GPMC_CD_FCLK,
+ GPMC_CD_CLK
+};
+
struct gpmc_cs_data {
const char *name;
@@ -268,16 +273,54 @@ static unsigned long gpmc_get_fclk_period(void)
return rate;
}
-static unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
+/**
+ * gpmc_get_clk_period - get period of selected clock domain in ps
+ * @cs Chip Select Region.
+ * @cd Clock Domain.
+ *
+ * GPMC_CS_CONFIG1 GPMCFCLKDIVIDER for cs has to be setup
+ * prior to calling this function with GPMC_CD_CLK.
+ */
+static unsigned long gpmc_get_clk_period(int cs, enum gpmc_clk_domain cd)
+{
+
+ unsigned long tick_ps = gpmc_get_fclk_period();
+ u32 l;
+ int div;
+
+ switch (cd) {
+ case GPMC_CD_CLK:
+ /* get current clk divider */
+ l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ div = (l 0x03) + 1;
+ /* get GPMC_CLK period */
+ tick_ps *= div;
+ break;
+ case GPMC_CD_FCLK:
+ /* FALL-THROUGH */
+ default:
+ break;
+ }
+
+ return tick_ps;
+
+}
+
+static unsigned int gpmc_ns_to_clk_ticks(unsigned int time_ns, int cs, enum
gpmc_clk_domain cd)
{
unsigned long tick_ps;
/* Calculate in picosecs to yield more exact results */
- tick_ps = gpmc_get_fclk_period();
+ tick_ps = gpmc_get_clk_period(cs, cd);
return (time_ns * 1000 + tick_ps - 1) / tick_ps;
}
+static unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
+{
+ return gpmc_ns_to_clk_ticks(time_ns, /* any CS */ 0, GPMC_CD_FCLK);
+}
+
static unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
{
unsigned long tick_ps;
@@ -288,9 +331,14 @@ static unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
return (time_ps + tick_ps - 1) / tick_ps;
}
+unsigned int gpmc_clk_ticks_to_ns(unsigned ticks, int cs, enum gpmc_clk_domain
cd)
+{
+ return ticks * gpmc_get_clk_period(cs, cd) / 1000;
+}
+
unsigned int gpmc_ticks_to_ns(unsigned int ticks)
{
- return ticks * gpmc_get_fclk_period() / 1000;
+ return gpmc_clk_ticks_to_ns(ticks, /* any CS */ 0, GPMC_CD_FCLK);
}
static unsigned int gpmc_ticks_to_ps(unsigned int ticks)
@@ -346,18 +394,24 @@ static void gpmc_cs_bool_timings(int cs, const struct
gpmc_bool_timings *p)
* @st_bit: Start Bit
* @end_bit: End Bit. Must be = @st_bit.
* @name:DTS node name, w/o gpmc,
+ * @cd: Clock Domain of timing parameter.
+ * @shift: Parameter value left shifts @shift, which is then printed instead
of value.
* @raw: Raw Format Option.
* raw format: gpmc,name = value
* tick format: gpmc,name = value /zwj;* x ns -- y ns; x ticks
*zwj;/
* Where x ns -- y ns result in the same tick value.
* @noval: Parameter values equal to 0 are not printed.
- * @shift: Parameter value left shifts @shift, which is then printed instead
of value.
* @return: Specified timing parameter (after optional @shift).
*
*/
-static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
- bool raw, bool noval, int shift,
- const char *name)
+static int get_gpmc_timing_reg(
+ /* timing specifiers */
+ int cs, int reg, int st_bit, int end_bit,
+ const char *name, const enum gpmc_clk_domain cd,
+ /* value transform */
+ int shift,
+ /* format specifiers */
+ bool raw, bool noval)
{
u32 l;
int nr_bits;
@@ -377,8 +431,8 @@ static int get_gpmc_timing_reg(int cs, int reg, int st_bit,
int end_bit,
unsigned int time_ns_min = 0;
if (l)
- time_ns_min = gpmc_ticks_to_ns(l - 1) + 1;
- time_ns = gpmc_ticks_to_ns(l);
+ time_ns_min = gpmc_clk_ticks_to_ns(l - 1, cs, cd) + 1;
+ time_ns = gpmc_clk_ticks_to_ns(l, cs, cd);
pr_info(gpmc,%s = %u /* %u ns - %u ns; %i ticks */\n,
[PATCH 6/8 v4] ARM OMAP2+ GPMC: calculate GPMCFCLKDIVIDER based on WAITMONITORINGTIME
The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
even though the access is defined as asynchronous, and no GPMC_CLK clock
is provided to the external device. Still, GPMCFCLKDIVIDER is used as a divider
for the GPMC clock, so it must be programmed to define the
correct WAITMONITORINGTIME delay.
Calculate GPMCFCLKDIVIDER independent of gpmc,sync-clk-ps in DT for
pure asynchronous accesses, i.e. both read and write asynchronous.
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
---
arch/arm/mach-omap2/gpmc-nand.c| 17
arch/arm/mach-omap2/gpmc-onenand.c | 4 +-
arch/arm/mach-omap2/usb-tusb6010.c | 4 +-
drivers/memory/omap-gpmc.c | 85 ++
include/linux/omap-gpmc.h | 2 +-
5 files changed, 92 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index d5951b1..e863a59 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -96,14 +96,6 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
gpmc_nand_res[1].start = gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
gpmc_nand_res[2].start = gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
- if (gpmc_t) {
- err = gpmc_cs_set_timings(gpmc_nand_data-cs, gpmc_t);
- if (err 0) {
- pr_err(omap2-gpmc: Unable to set gpmc timings: %d\n,
err);
- return err;
- }
- }
-
memset(s, 0, sizeof(struct gpmc_settings));
if (gpmc_nand_data-of_node)
gpmc_read_settings_dt(gpmc_nand_data-of_node, s);
@@ -111,6 +103,15 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
gpmc_set_legacy(gpmc_nand_data, s);
s.device_nand = true;
+
+ if (gpmc_t) {
+ err = gpmc_cs_set_timings(gpmc_nand_data-cs, gpmc_t, s);
+ if (err 0) {
+ pr_err(omap2-gpmc: Unable to set gpmc timings: %d\n,
err);
+ return err;
+ }
+ }
+
err = gpmc_cs_program_settings(gpmc_nand_data-cs, s);
if (err 0)
goto out_free_cs;
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 53d197e..f899e77 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -293,7 +293,7 @@ static int omap2_onenand_setup_async(void __iomem
*onenand_base)
if (ret 0)
return ret;
- ret = gpmc_cs_set_timings(gpmc_onenand_data-cs, t);
+ ret = gpmc_cs_set_timings(gpmc_onenand_data-cs, t, onenand_async);
if (ret 0)
return ret;
@@ -331,7 +331,7 @@ static int omap2_onenand_setup_sync(void __iomem
*onenand_base, int *freq_ptr)
if (ret 0)
return ret;
- ret = gpmc_cs_set_timings(gpmc_onenand_data-cs, t);
+ ret = gpmc_cs_set_timings(gpmc_onenand_data-cs, t, onenand_sync);
if (ret 0)
return ret;
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c
b/arch/arm/mach-omap2/usb-tusb6010.c
index 8333400..e554d9e 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -71,7 +71,7 @@ static int tusb_set_async_mode(unsigned sysclk_ps)
gpmc_calc_timings(t, tusb_async, dev_t);
- return gpmc_cs_set_timings(async_cs, t);
+ return gpmc_cs_set_timings(async_cs, t, tusb_async);
}
static int tusb_set_sync_mode(unsigned sysclk_ps)
@@ -98,7 +98,7 @@ static int tusb_set_sync_mode(unsigned sysclk_ps)
gpmc_calc_timings(t, tusb_sync, dev_t);
- return gpmc_cs_set_timings(sync_cs, t);
+ return gpmc_cs_set_timings(sync_cs, t, tusb_sync);
}
/* tusb driver calls this when it changes the chip's clocking */
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 02e5228..8ee335d 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -138,7 +138,9 @@
#define GPMC_CONFIG1_PAGE_LEN(val) ((val 3) 23)
#define GPMC_CONFIG1_WAIT_READ_MON (1 22)
#define GPMC_CONFIG1_WAIT_WRITE_MON (1 21)
-#define GPMC_CONFIG1_WAIT_MON_IIME(val) ((val 3) 18)
+#define GPMC_CONFIG1_WAIT_MON_TIME(val) ((val 3) 18)
+/** WAITMONITORINGTIME Max Ticks */
+#define GPMC_CONFIG1_WAITMONITORINGTIME_MAX 2
#define GPMC_CONFIG1_WAIT_PIN_SEL(val) ((val 3) 16)
#define GPMC_CONFIG1_DEVICESIZE(val)((val 3) 12)
#define GPMC_CONFIG1_DEVICESIZE_16 GPMC_CONFIG1_DEVICESIZE(1)
@@ -516,13 +518,48 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
t-field, #field) 0) \
return -1
+/**
+ * gpmc_calc_waitmonitoring_divider - calculate proper GPMCFCLKDIVIDER based
on WAITMONITORINGTIME
+ * WAITMONITORINGTIME will be _at least_ as long as desired, i.e.
+ * read -- don't sample bus
[PATCH 2/8 v4] ARM OMAP2+ GPMC: add bus children
This patch adds support for spawning buses as children of the GPMC. Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de --- drivers/memory/omap-gpmc.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c index 5cabac8..74a8c52 100644 --- a/drivers/memory/omap-gpmc.c +++ b/drivers/memory/omap-gpmc.c @@ -27,6 +27,7 @@ #include linux/of_address.h #include linux/of_mtd.h #include linux/of_device.h +#include linux/of_platform.h #include linux/omap-gpmc.h #include linux/mtd/nand.h #include linux/pm_runtime.h @@ -1800,8 +1801,20 @@ static int gpmc_probe_generic_child(struct platform_device *pdev, gpmc_cs_enable_mem(cs); no_timings: - if (of_platform_device_create(child, NULL, pdev-dev)) - return 0; + + /* create platform device, NULL on error or when disabled */ + if (!of_platform_device_create(child, NULL, pdev-dev)) + goto err_child_fail; + + /* is child a common bus? */ + if (of_match_node(of_default_bus_match_table, child)) + /* create children and other common bus children */ + if (of_platform_populate(child, of_default_bus_match_table, NULL, pdev-dev)) + goto err_child_fail; + + return 0; + +err_child_fail: dev_err(pdev-dev, failed to create gpmc child %s\n, child-name); ret = -ENODEV; -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8 v4] ARM OMAP2+ GPMC: fix debug output alignment
GPMC debug output is aligned to 10 characters for field names. However, some fields have bigger names, screwing up the alignment. Consequently, alignment was changed to longest field name (17 chars) for now. Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de --- drivers/memory/omap-gpmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c index 74a8c52..dbb6753 100644 --- a/drivers/memory/omap-gpmc.c +++ b/drivers/memory/omap-gpmc.c @@ -482,7 +482,7 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit, l = gpmc_cs_read_reg(cs, reg); #ifdef DEBUG printk(KERN_INFO - GPMC CS%d: %-10s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n, + GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n, cs, name, ticks, gpmc_get_fclk_period() * ticks / 1000, (l st_bit) mask, time); #endif -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] ARM: dts: add openpandora device support
* Belisko Marek marek.beli...@gmail.com [150227 00:37]: Tony, should I send v3 (with updates) or can you apply current version? Thanks. Well if you trust me a) to rembember to apply the patches b) remember to apply the ack c) remember to fix the pin d) actually get it done right when I do it, then sure I can apply them. Seriously, it's usually best to repost if changes are needed because otherwise things can go wrong and things can get a bit overwhelming for me here and there :) Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bluetooth on n900 -- working patch
On Wednesday 11 February 2015 11:41:36 Pavel Machek wrote: Hi! Here's current version of the bluetooth patch, I hope I did not miss anything. This time including dts changes, so that driver is active. I have firmware in /lib/firmware/nokia/bcmfw.bin Best regards, Pavel Do you have userspace application for initializing mac address? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: 3.20-rc0 breaks nfsroot over usb
On Fri 2015-02-27 01:03:07, Aaro Koskinen wrote: Hi, On Thu, Feb 26, 2015 at 11:19:50PM +0100, Pavel Machek wrote: Ok, it seems that new config dependencies broke my kconfig. These will not be enabled if you just to make oldconfig; you want to make sure they are on. OMAP2430 and onwards (USB_MUSB_OMAP2PLUS) [N/m/y] (NEW) TWL4030 USB Transceiver Driver (TWL4030_USB) [N/m/y/?] (NEW) Yes, also other users have reported USB breakage with 4.0-rc1 on N900 etc caused by this. Commit fbba7db3990cb707ff91cd6507d53a0a730afe97 (usb: musb: add omap-control dependency) changed USB_MUSB_OMAP2PLUS to depend Too bad noone told me. I had a lot of fun trying to bisect config problem. I have yet to try the nfsroot, but I guess it should be ok now. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.20-rc0 breaks nfsroot over usb
On Friday 27 February 2015 07:38:09 Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [150226 15:06]: Hi, On Thu, Feb 26, 2015 at 11:19:50PM +0100, Pavel Machek wrote: Ok, it seems that new config dependencies broke my kconfig. These will not be enabled if you just to make oldconfig; you want to make sure they are on. OMAP2430 and onwards (USB_MUSB_OMAP2PLUS) [N/m/y] (NEW) TWL4030 USB Transceiver Driver (TWL4030_USB) [N/m/y/?] (NEW) Yes, also other users have reported USB breakage with 4.0-rc1 on N900 etc caused by this. Commit fbba7db3990cb707ff91cd6507d53a0a730afe97 (usb: musb: add omap-control dependency) changed USB_MUSB_OMAP2PLUS to depend on OMAP_CONTROL_PHY but that seems to be wrong at least for OMAP3. omap_control_phy.h provides dummy functions when it's not enabled. So there should be no dependency. The problem I fixed was a link error when USB_MUSB_OMAP2PLUS is built-in but OMAP_CONTROL_PHY is a loadable module. I guess the solution would be to make drivers/phy handle whatever omap_control_usb_set_mode is doing in a generic way. I'm very sorry about the breakage in a patch that is marked for backports. Please accept my apology and the workaround patch in the follow-up mail. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bluetooth on n900 -- working patch
Hi!
Here's current version of the bluetooth patch, I hope I did
not miss anything. This time including dts changes, so that
driver is active.
I have firmware in /lib/firmware/nokia/bcmfw.bin
Best regards,
Pavel
Do you have userspace application for initializing mac address?
bluez-5.26 should be able to do the trick. Non-mandatory patch below.
I'm using
../bluez-5.26/tools/btmgmt public-addr 01:02:03:04:05:06
diff -ur bluez-5.26.ofic/tools/btmgmt.c bluez-5.26/tools/btmgmt.c
--- bluez-5.26.ofic/tools/btmgmt.c 2014-12-14 12:32:19.742595000 +0100
+++ bluez-5.26/tools/btmgmt.c 2014-12-14 20:06:40.432497973 +0100
@@ -2603,7 +2603,7 @@
static void static_addr_usage(void)
{
- printf(Usage: btmgmt static-addr address\n);
+ printf(Usage: btmgmt static-addr ??:??:??:??:??:??\n);
}
static void cmd_static_addr(struct mgmt *mgmt, uint16_t index,
@@ -2660,7 +2660,8 @@
struct mgmt_cp_set_public_address cp;
if (argc 2) {
- printf(Usage: btmgmt public-addr address\n);
+ printf(Usage: btmgmt public-addr ??:??:??:??:??:??\n
+ Note: interface must be down for this to work\n);
exit(EXIT_FAILURE);
}
@@ -2934,7 +2935,7 @@
static void add_device_usage(void)
{
- printf(Usage: btmgmt add-device [-a action] [-t type] address\n);
+ printf(Usage: btmgmt add-device [-a action] [-t type]
??:??:??:??:??:??\n);
}
static struct option add_device_options[] = {
@@ -3007,7 +3008,7 @@
static void del_device_usage(void)
{
- printf(Usage: btmgmt del-device [-t type] address\n);
+ printf(Usage: btmgmt del-device [-t type] ??:??:??:??:??:??\n);
}
static struct option del_device_options[] = {
@@ -3153,7 +3154,7 @@
printf(\n
For more information on the usage of each command use:\n
- \tbtmgmt command --help\n );
+ \tbtmgmt command\n );
}
static struct option main_options[] = {
Only in bluez-5.26/tools: btmgmt.c~
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: fix Kconfig regression
On Fri, Feb 27, 2015 at 09:12:45PM +0100, Arnd Bergmann wrote: A recent bug fix I did that was marked for stable backports introduced a slightly wrong dependency on CONFIG_OMAP_CONTROL_PHY. I was missing the fact that the PHY driver already stubs out the omap_control_usb_set_mode, and we only need to add a dependency to prevent the musb-omap2430 driver from being built-in when the phy driver is a loadable module, but we should not prevent it from being built altogether when the phy driver is disabled. This changes the dependency to allow OMAP_CONTROL_PHY to be disabled, but to disallow USB_MUSB_OMAP2PLUS from being built-in if OMAP_CONTROL_PHY is a loadable module. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: ca784be36cc725 (usb: start using the control module driver) Cc: sta...@vger.kernel.org # v3.9+ Cc: Felipe Balbi ba...@ti.com please resend with linux-usb in Cc and myself in Cc too ;-) -- balbi signature.asc Description: Digital signature
[PATCH] usb: musb: fix Kconfig regression
A recent bug fix I did that was marked for stable backports introduced a slightly wrong dependency on CONFIG_OMAP_CONTROL_PHY. I was missing the fact that the PHY driver already stubs out the omap_control_usb_set_mode, and we only need to add a dependency to prevent the musb-omap2430 driver from being built-in when the phy driver is a loadable module, but we should not prevent it from being built altogether when the phy driver is disabled. This changes the dependency to allow OMAP_CONTROL_PHY to be disabled, but to disallow USB_MUSB_OMAP2PLUS from being built-in if OMAP_CONTROL_PHY is a loadable module. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: ca784be36cc725 (usb: start using the control module driver) Cc: sta...@vger.kernel.org # v3.9+ Cc: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 14e1628483d9..39db8b603627 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -79,7 +79,8 @@ config USB_MUSB_TUSB6010 config USB_MUSB_OMAP2PLUS tristate OMAP2430 and onwards - depends on ARCH_OMAP2PLUS USB OMAP_CONTROL_PHY + depends on ARCH_OMAP2PLUS USB + depends on OMAP_CONTROL_PHY || !OMAP_CONTROL_PHY select GENERIC_PHY config USB_MUSB_AM35X -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: dts: OMAP5: fix polling intervals for thermal zones
On Fri, Feb 27, 2015 at 03:59:03PM +0200, Tero Kristo wrote:
OMAP4 has a finer counter granularity, which allows for a delay of 1000ms
in the thermal zone polling intervals. OMAP5 has a different counter
mechanism, which allows at maximum a 500ms timer. Adjust the cpu thermal
zone polling interval accordingly.
Without this patch, the polling interval information is simply ignored,
and the following thermal warnings are printed during boot (assuming
thermal is enabled);
[1.545343] ti-soc-thermal 4a0021e0.bandgap: Delay 1000 ms is not supported
[1.552691] ti-soc-thermal 4a0021e0.bandgap: Delay 1000 ms is not supported
[1.560029] ti-soc-thermal 4a0021e0.bandgap: Delay 1000 ms is not supported
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Tony Lindgren t...@atomide.com
Acked-by: Eduardo Valentin edubez...@gmail.com
---
arch/arm/boot/dts/omap5-core-thermal.dtsi |2 +-
arch/arm/boot/dts/omap5-gpu-thermal.dtsi |2 +-
arch/arm/boot/dts/omap5.dtsi |4
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-core-thermal.dtsi
b/arch/arm/boot/dts/omap5-core-thermal.dtsi
index 19212ac..de8a3d4 100644
--- a/arch/arm/boot/dts/omap5-core-thermal.dtsi
+++ b/arch/arm/boot/dts/omap5-core-thermal.dtsi
@@ -13,7 +13,7 @@
core_thermal: core_thermal {
polling-delay-passive = 250; /* milliseconds */
- polling-delay = 1000; /* milliseconds */
+ polling-delay = 500; /* milliseconds */
/* sensor ID */
thermal-sensors = bandgap 2;
diff --git a/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
index 1b87aca..bc3090f 100644
--- a/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
+++ b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
@@ -13,7 +13,7 @@
gpu_thermal: gpu_thermal {
polling-delay-passive = 250; /* milliseconds */
- polling-delay = 1000; /* milliseconds */
+ polling-delay = 500; /* milliseconds */
/* sensor ID */
thermal-sensors = bandgap 1;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b321fdf..fee1580 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -1079,4 +1079,8 @@
};
};
+cpu_thermal {
+ polling-delay = 500; /* milliseconds */
+};
+
/include/ omap54xx-clocks.dtsi
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
signature.asc
Description: Digital signature
[PATCH v3 3/3] ARM: dts: omap3-pandora: add DM3730 1 GHz version
From: H. Nikolaus Schaller h...@goldelico.com
Added Pandora 1 GHz model which is based on Classic/Rebirth
with following changes:
- upgraded cpu to dm3730 runs on 1GHz
- 512 MiB DDR-333 SDRAM @ 200 MHz
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
Tested-by: Grazvydas Ignotas nota...@gmail.com
Reviewed-by: Grazvydas Ignotas nota...@gmail.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3-pandora-1ghz.dts | 70
2 files changed, 71 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-pandora-1ghz.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index eddbeee..69f3106 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -344,6 +344,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-overo-summit.dtb \
omap3-overo-tobi.dtb \
omap3-pandora-600mhz.dtb \
+ omap3-pandora-1ghz.dtb \
omap3-sbc-t3517.dtb \
omap3-sbc-t3530.dtb \
omap3-sbc-t3730.dtb \
diff --git a/arch/arm/boot/dts/omap3-pandora-1ghz.dts
b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
new file mode 100644
index 000..9619a28
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-pandora-1ghz.dts
@@ -0,0 +1,70 @@
+/*
+ * Copyright (C) 2015
+ * Nikolaus Schaller h...@goldelico.com
+ *
+ * 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.
+ */
+
+/*
+ * device tree for OpenPandora 1GHz with DM3730
+ */
+
+/dts-v1/;
+
+#include omap36xx.dtsi
+#include omap3-pandora-common.dtsi
+
+/ {
+ model = Pandora Handheld Console 1GHz;
+
+ compatible = ti,omap36xx, ti,omap3;
+};
+
+omap3_pmx_core2 {
+
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusb2_2_pins
+ control_pins
+ ;
+
+ hsusb2_2_pins: pinmux_hsusb2_2_pins {
+ pinctrl-single,pins =
+ OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
+ OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
+ OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d12.hsusb2_dir */
+ OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d13.hsusb2_nxt */
+ OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d14.hsusb2_data0 */
+ OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d15.hsusb2_data1 */
+ ;
+ };
+
+ mmc3_pins: pinmux_mmc3_pins {
+ pinctrl-single,pins =
+ OMAP3630_CORE2_IOPAD(0x25d8, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_clk.sdmmc3_clk */
+ OMAP3630_CORE2_IOPAD(0x25da, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_ctl.sdmmc3_cmd */
+ OMAP3630_CORE2_IOPAD(0x25e2, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d3.sdmmc3_dat3 */
+ OMAP3630_CORE2_IOPAD(0x25e4, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d4.sdmmc3_dat0 */
+ OMAP3630_CORE2_IOPAD(0x25e6, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d5.sdmmc3_dat1 */
+ OMAP3630_CORE2_IOPAD(0x25e8, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d6.sdmmc3_dat2 */
+ ;
+ };
+
+ control_pins: pinmux_control_pins {
+ pinctrl-single,pins =
+ OMAP3630_CORE2_IOPAD(0x25dc, PIN_INPUT_PULLDOWN |
MUX_MODE4)/* etk_d0.gpio_14 = HP_SHUTDOWN */
+ OMAP3630_CORE2_IOPAD(0x25de, PIN_OUTPUT | MUX_MODE4)
/* etk_d1.gpio_15 = BT_SHUTDOWN */
+ OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
/* etk_d2.gpio_16 = RESET_USB_HOST */
+ OMAP3630_CORE2_IOPAD(0x25ea, PIN_INPUT | MUX_MODE4)
/* etk_d7.gpio_21 = WIFI IRQ */
+ OMAP3630_CORE2_IOPAD(0x25ec, PIN_OUTPUT | MUX_MODE4)
/* etk_d8.gpio_22 = MSECURE */
+ OMAP3630_CORE2_IOPAD(0x25ee, PIN_OUTPUT | MUX_MODE4)
/* etk_d9.gpio_23 = WIFI_POWER */
+ OMAP3_WKUP_IOPAD(0x2a54, PIN_INPUT | MUX_MODE4)
/* reserved.gpio_127 = MMC2_WP */
+ OMAP3_WKUP_IOPAD(0x2a56, PIN_INPUT | MUX_MODE4)
/* reserved.gpio_126 = MMC1_WP */
+ OMAP3_WKUP_IOPAD(0x2a58, PIN_OUTPUT | MUX_MODE4)
/* reserved.gpio_128 = LED_MMC1 */
+ OMAP3_WKUP_IOPAD(0x2a5a, PIN_OUTPUT | MUX_MODE4)
/* reserved.gpio_129 = LED_MMC2 */
+
+ ;
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
[PATCH v3 1/3] ARM: dts: omap3-pandora: add common device tree
From: H. Nikolaus Schaller h...@goldelico.com
This device tree allows to boot, supports the panel,
framebuffer, touch screen, as well as some more peripherals.
Since there is a OMAP3530 based 600 MHz variant and a DM3730 based
1 GHz variant we must include this common device tree code
in one of two CPU specific device trees.
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: Marek Belisko ma...@goldelico.com
Tested-by: Grazvydas Ignotas nota...@gmail.com
Reviewed-by: Grazvydas Ignotas nota...@gmail.com
---
arch/arm/boot/dts/omap3-pandora-common.dtsi | 640
1 file changed, 640 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-pandora-common.dtsi
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
new file mode 100644
index 000..782ab1f
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -0,0 +1,640 @@
+/*
+ * Copyright (C) 2015
+ * Nikolaus Schaller h...@goldelico.com
+ *
+ * Common device tree include for OpenPandora devices.
+ *
+ * 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/input/input.h
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+
+ aliases {
+ display0 = lcd;
+ };
+
+ tv: connector@1 {
+ compatible = connector-analog-tv;
+ label = tv;
+
+ port {
+ tv_connector_in: endpoint {
+ remote-endpoint = venc_out;
+ };
+ };
+ };
+
+ gpio-leds {
+
+ compatible = gpio-leds;
+
+ pinctrl-names = default;
+ pinctrl-0 = led_pins;
+
+ led@1 {
+ label = pandora::sd1;
+ gpios = gpio5 0 GPIO_ACTIVE_HIGH;/* GPIO_128 */
+ linux,default-trigger = mmc0;
+ default-state = off;
+ };
+
+ led@2 {
+ label = pandora::sd2;
+ gpios = gpio5 1 GPIO_ACTIVE_HIGH;/* GPIO_129 */
+ linux,default-trigger = mmc1;
+ default-state = off;
+ };
+
+ led@3 {
+ label = pandora::bluetooth;
+ gpios = gpio5 30 GPIO_ACTIVE_HIGH; /* GPIO_158 */
+ linux,default-trigger = heartbeat;
+ default-state = off;
+ };
+
+ led@4 {
+ label = pandora::wifi;
+ gpios = gpio5 31 GPIO_ACTIVE_HIGH; /* GPIO_159 */
+ linux,default-trigger = mmc2;
+ default-state = off;
+ };
+ };
+
+ gpio-keys {
+ compatible = gpio-keys;
+
+ pinctrl-names = default;
+ pinctrl-0 = button_pins;
+
+ up-button {
+ label = up;
+ linux,code = KEY_UP;
+ gpios = gpio4 14 GPIO_ACTIVE_LOW;/* GPIO_110 */
+ gpio-key,wakeup;
+ };
+
+ down-button {
+ label = down;
+ linux,code = KEY_DOWN;
+ gpios = gpio4 7 GPIO_ACTIVE_LOW; /* GPIO_103 */
+ gpio-key,wakeup;
+ };
+
+ left-button {
+ label = left;
+ linux,code = KEY_LEFT;
+ gpios = gpio4 0 GPIO_ACTIVE_LOW; /* GPIO_96 */
+ gpio-key,wakeup;
+ };
+
+ right-button {
+ label = right;
+ linux,code = KEY_RIGHT;
+ gpios = gpio4 2 GPIO_ACTIVE_LOW; /* GPIO_98 */
+ gpio-key,wakeup;
+ };
+
+ pageup-button {
+ label = game 1;
+ linux,code = KEY_PAGEUP;
+ gpios = gpio4 13 GPIO_ACTIVE_LOW;/* GPIO_109 */
+ gpio-key,wakeup;
+ };
+
+ pagedown-button {
+ label = game 3;
+ linux,code = KEY_PAGEDOWN;
+ gpios = gpio4 10 GPIO_ACTIVE_LOW;/* GPIO_106 */
+ gpio-key,wakeup;
+ };
+
+ home-button {
+ label = game 4;
+ linux,code = KEY_HOME;
+ gpios = gpio4 5
[PATCH v3 2/3] ARM: dts: omap3-pandora: add OMAP3530 600 MHz version
From: H. Nikolaus Schaller h...@goldelico.com
Added Pandora Rebirth model which is based on Pandora
Classic with 512 MiB DDR-333 SDRAM memory.
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
Tested-by: Grazvydas Ignotas nota...@gmail.com
Reviewed-by: Grazvydas Ignotas nota...@gmail.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3-pandora-600mhz.dts | 65 ++
2 files changed, 66 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-pandora-600mhz.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 91bd5bd..eddbeee 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -343,6 +343,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-overo-storm-tobi.dtb \
omap3-overo-summit.dtb \
omap3-overo-tobi.dtb \
+ omap3-pandora-600mhz.dtb \
omap3-sbc-t3517.dtb \
omap3-sbc-t3530.dtb \
omap3-sbc-t3730.dtb \
diff --git a/arch/arm/boot/dts/omap3-pandora-600mhz.dts
b/arch/arm/boot/dts/omap3-pandora-600mhz.dts
new file mode 100644
index 000..fb803a7
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-pandora-600mhz.dts
@@ -0,0 +1,65 @@
+/*
+ * Copyright (C) 2015
+ * Nikolaus Schaller h...@goldelico.com
+ *
+ * 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.
+ */
+
+/*
+ * device tree for OpenPandora with OMAP3530
+ */
+
+/dts-v1/;
+
+#include omap34xx.dtsi
+#include omap3-pandora-common.dtsi
+
+/ {
+ model = Pandora Handheld Console;
+
+ compatible = ti,omap3;
+};
+
+omap3_pmx_core2 {
+
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusb2_2_pins
+ control_pins
+ ;
+
+ hsusb2_2_pins: pinmux_hsusb2_2_pins {
+ pinctrl-single,pins =
+ OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
+ OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
+ OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d12.hsusb2_dir */
+ OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d13.hsusb2_nxt */
+ OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d14.hsusb2_data0 */
+ OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d15.hsusb2_data1 */
+ ;
+ };
+
+ mmc3_pins: pinmux_mmc3_pins {
+ pinctrl-single,pins =
+ OMAP3430_CORE2_IOPAD(0x25d8, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_clk.sdmmc3_clk */
+ OMAP3430_CORE2_IOPAD(0x25da, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_ctl.sdmmc3_cmd */
+ OMAP3430_CORE2_IOPAD(0x25e2, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d3.sdmmc3_dat3 */
+ OMAP3430_CORE2_IOPAD(0x25e4, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d4.sdmmc3_dat0 */
+ OMAP3430_CORE2_IOPAD(0x25e6, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d5.sdmmc3_dat1 */
+ OMAP3430_CORE2_IOPAD(0x25e8, PIN_INPUT_PULLUP |
MUX_MODE2) /* etk_d6.sdmmc3_dat2 */
+ ;
+ };
+
+ control_pins: pinmux_control_pins {
+ pinctrl-single,pins =
+ OMAP3430_CORE2_IOPAD(0x25dc, PIN_INPUT_PULLDOWN |
MUX_MODE4)/* etk_d0.gpio_14 = HP_SHUTDOWN */
+ OMAP3430_CORE2_IOPAD(0x25de, PIN_OUTPUT | MUX_MODE4)
/* etk_d1.gpio_15 = BT_SHUTDOWN */
+ OMAP3430_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
/* etk_d2.gpio_16 = RESET_USB_HOST */
+ OMAP3430_CORE2_IOPAD(0x25ea, PIN_INPUT | MUX_MODE4)
/* etk_d7.gpio_21 = WIFI IRQ */
+ OMAP3430_CORE2_IOPAD(0x25ec, PIN_OUTPUT | MUX_MODE4)
/* etk_d8.gpio_22 = MSECURE */
+ OMAP3430_CORE2_IOPAD(0x25ee, PIN_OUTPUT | MUX_MODE4)
/* etk_d9.gpio_23 = WIFI_POWER */
+ ;
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] ARM: dts: add openpandora device support
changes from v2: - fix missing PIN_INPUT for penirq node - added Reviewed-by and Tested-by changes from v1: - add new boards to makefile in patch 2,3 (don't add them in separate commit together), fix gpmc issues (reported by Tony Lindgren) - fix various issues reported by Grazvydas Ignotas (drop internal pullups from pinmux as external are in place, fix gpio buttons active state ...) This series of patches adds initial device tree support for the OpenPandora. The most important parts are working (display, keyboard, touch, charging, fuel gauge, musb port, sd/mmc ports, leds, buttons). Not yet supported are: usb host port, nubs, wifi, bluetooth, audio. First patch add common dtsi file which is then used in 600mhz and 1ghz variants of openpandora which support is added in patches 2 and 3. H. Nikolaus Schaller (3): ARM: dts: omap3-pandora: add common device tree ARM: dts: omap3-pandora: add OMAP3530 600 MHz version ARM: dts: omap3-pandora: add DM3730 1 GHz version arch/arm/boot/dts/Makefile | 2 + arch/arm/boot/dts/omap3-pandora-1ghz.dts| 70 +++ arch/arm/boot/dts/omap3-pandora-600mhz.dts | 65 +++ arch/arm/boot/dts/omap3-pandora-common.dtsi | 640 4 files changed, 777 insertions(+) create mode 100644 arch/arm/boot/dts/omap3-pandora-1ghz.dts create mode 100644 arch/arm/boot/dts/omap3-pandora-600mhz.dts create mode 100644 arch/arm/boot/dts/omap3-pandora-common.dtsi -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] ARM: dts: add openpandora device support
Tony, should I send v3 (with updates) or can you apply current version? Thanks. On Thu, Feb 19, 2015 at 11:55 PM, Grazvydas Ignotas nota...@gmail.com wrote: On Tue, Feb 17, 2015 at 9:52 PM, Marek Belisko ma...@goldelico.com wrote: changes from v1: - add new boards to makefile in patch 2,3 (don't add them in separate commit together), fix gpmc issues (reported by Tony Lindgren) - fix various issues reported by Grazvydas Ignotas (drop internal pullups from pinmux as external are in place, fix gpio buttons active state ...) This series of patches adds initial device tree support for the OpenPandora. The most important parts are working (display, keyboard, touch, charging, fuel gauge, musb port, sd/mmc ports, leds, buttons). All of these have been tested to be working, after adding missing input flag for touchscreen. Well except musb, but I often have trouble with that in mainline, probably not a problem with this dts. Tested-by: Grazvydas Ignotas nota...@gmail.com And FWIW, the patches have been Reviewed-by: Grazvydas Ignotas nota...@gmail.com Marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add support for HDQ-1W on AM43XX
Hi, This patch series adds support for HDQ-1W interface on AM43XX. The first patch adds hwmod entries for HDQ-1W on AM43xx. The existing omap_hdq driver does not support 1-wire operations. The second patch enables 1-wire support in the omap_hdq driver. Support to Search ROM addresses and automatically load slave drivers is added for 1-wire mode. I have tested this on am437x-gp-evm using DS18B20 as 1-wire slave. Poddar, Sourav (1): ARM: OMAP2: hwmod: AM43XX: Add hwmod support for HDQ-1W Vignesh R (1): w1: masters: omap_hdq: Add support for 1-wire mode Documentation/devicetree/bindings/w1/omap-hdq.txt | 7 +- Documentation/w1/masters/omap-hdq | 6 + arch/arm/mach-omap2/omap_hwmod_43xx_data.c| 36 arch/arm/mach-omap2/prcm43xx.h| 1 + drivers/w1/masters/omap_hdq.c | 209 ++ 5 files changed, 225 insertions(+), 34 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] w1: masters: omap_hdq: Add support for 1-wire mode
This patches makes following changes to omap_hdq driver
- Enable 1-wire mode.
- Implement w1_triplet callback to facilitate search ROM
procedure and auto detection of 1-wire slaves.
- Proper enabling and disabling of interrupt.
- Cleanups (formatting and return value checks).
HDQ mode remains unchanged.
Signed-off-by: Vignesh R vigne...@ti.com
---
Documentation/devicetree/bindings/w1/omap-hdq.txt | 7 +-
Documentation/w1/masters/omap-hdq | 6 +
drivers/w1/masters/omap_hdq.c | 209 ++
3 files changed, 188 insertions(+), 34 deletions(-)
diff --git a/Documentation/devicetree/bindings/w1/omap-hdq.txt
b/Documentation/devicetree/bindings/w1/omap-hdq.txt
index fef794741bd1..3927b9c910bd 100644
--- a/Documentation/devicetree/bindings/w1/omap-hdq.txt
+++ b/Documentation/devicetree/bindings/w1/omap-hdq.txt
@@ -1,11 +1,15 @@
* OMAP HDQ One wire bus master controller
Required properties:
-- compatible : should be ti,omap3-1w
+- compatible : should be ti,omap3-1w or ti,am43xx-hdq
- reg : Address and length of the register set for the device
- interrupts : interrupt line.
- ti,hwmods : hdq1w
+Optional properties:
+- ti,mode: should be hdq: HDQ mode 1w: one-wire mode.
+ If not specified HDQ mode is implied.
+
Example:
- From omap3.dtsi
@@ -14,4 +18,5 @@ Example:
reg = 0x480b2000 0x1000;
interrupts = 58;
ti,hwmods = hdq1w;
+ ti,mode = hdq;
};
diff --git a/Documentation/w1/masters/omap-hdq
b/Documentation/w1/masters/omap-hdq
index 884dc284b215..234522709a5f 100644
--- a/Documentation/w1/masters/omap-hdq
+++ b/Documentation/w1/masters/omap-hdq
@@ -44,3 +44,9 @@ e.g:
insmod omap_hdq.ko W1_ID=2
inamod w1_bq27000.ko F_ID=2
+The driver also supports 1-wire mode. In this mode, there is no need to
+pass slave ID as parameter. The driver will auto-detect slaves connected
+to the bus using SEARCH_ROM procedure. 1-wire mode can be selected by
+setting ti,mode property to 1w in DT (see
+Documentation/devicetree/bindings/w1/omap-hdq.txt for more details).
+By default driver is in HDQ mode.
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index 03321d6a2684..5616bc331489 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
@@ -17,6 +17,7 @@
#include linux/io.h
#include linux/sched.h
#include linux/pm_runtime.h
+#include linux/of.h
#include ../w1.h
#include ../w1_int.h
@@ -27,21 +28,23 @@
#define OMAP_HDQ_TX_DATA 0x04
#define OMAP_HDQ_RX_DATA 0x08
#define OMAP_HDQ_CTRL_STATUS 0x0c
-#define OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK (16)
-#define OMAP_HDQ_CTRL_STATUS_CLOCKENABLE (15)
-#define OMAP_HDQ_CTRL_STATUS_GO(14)
-#define OMAP_HDQ_CTRL_STATUS_INITIALIZATION(12)
-#define OMAP_HDQ_CTRL_STATUS_DIR (11)
-#define OMAP_HDQ_CTRL_STATUS_MODE (10)
+#define OMAP_HDQ_CTRL_STATUS_SINGLEBIT(7)
+#define OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK BIT(6)
+#define OMAP_HDQ_CTRL_STATUS_CLOCKENABLE BIT(5)
+#define OMAP_HDQ_CTRL_STATUS_GO BIT(4)
+#define OMAP_HDQ_CTRL_STATUS_PRESENCE BIT(3)
+#define OMAP_HDQ_CTRL_STATUS_INITIALIZATIONBIT(2)
+#define OMAP_HDQ_CTRL_STATUS_DIR BIT(1)
#define OMAP_HDQ_INT_STATUS0x10
-#define OMAP_HDQ_INT_STATUS_TXCOMPLETE (12)
-#define OMAP_HDQ_INT_STATUS_RXCOMPLETE (11)
-#define OMAP_HDQ_INT_STATUS_TIMEOUT(10)
+#define OMAP_HDQ_INT_STATUS_TXCOMPLETE BIT(2)
+#define OMAP_HDQ_INT_STATUS_RXCOMPLETE BIT(1)
+#define OMAP_HDQ_INT_STATUS_TIMEOUTBIT(0)
#define OMAP_HDQ_SYSCONFIG 0x14
-#define OMAP_HDQ_SYSCONFIG_SOFTRESET (11)
-#define OMAP_HDQ_SYSCONFIG_AUTOIDLE(10)
+#define OMAP_HDQ_SYSCONFIG_SOFTRESET BIT(1)
+#define OMAP_HDQ_SYSCONFIG_AUTOIDLEBIT(0)
+#define OMAP_HDQ_SYSCONFIG_NOIDLE BIT(0)
#define OMAP_HDQ_SYSSTATUS 0x18
-#define OMAP_HDQ_SYSSTATUS_RESETDONE (10)
+#define OMAP_HDQ_SYSSTATUS_RESETDONE BIT(0)
#define OMAP_HDQ_FLAG_CLEAR0
#define OMAP_HDQ_FLAG_SET 1
@@ -67,6 +70,10 @@ struct hdq_data {
* the data wrire or read.
*/
int init_trans;
+ int rrw;
+ /* mode: 0-HDQ 1-W1 */
+ int mode;
+
};
static int omap_hdq_probe(struct platform_device *pdev);
@@ -74,6 +81,7 @@ static int omap_hdq_remove(struct platform_device *pdev);
static struct of_device_id omap_hdq_dt_ids[] = {
{ .compatible = ti,omap3-1w },
+ { .compatible = ti,am43xx-hdq },
{}
};
MODULE_DEVICE_TABLE(of, omap_hdq_dt_ids);
@@ -90,15 +98,12 @@ static struct platform_driver omap_hdq_driver = {
static u8 omap_w1_read_byte(void
[PATCH 1/2] ARM: OMAP2: hwmod: AM43XX: Add hwmod support for HDQ-1W
From: Poddar, Sourav sourav.pod...@ti.com
This patch adds hwmod data for hdq/1w driver on AM43xx.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
[vigne...@ti.com: Ported patch to v4.0-rc1]
Signed-off-by: Vignesh R vigne...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 36 ++
arch/arm/mach-omap2/prcm43xx.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 8eb85925e444..d4f1df28475c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -20,6 +20,7 @@
#include omap_hwmod_33xx_43xx_common_data.h
#include prcm43xx.h
#include omap_hwmod_common_data.h
+#include hdq1w.h
/* IP blocks */
@@ -516,6 +517,33 @@ static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
.parent_hwmod = am43xx_dss_core_hwmod,
};
+/* HDQ1W */
+static struct omap_hwmod_class_sysconfig am43xx_hdq1w_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0014,
+ .syss_offs = 0x0018,
+ .sysc_flags = (SYSC_HAS_SOFTRESET),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_hdq1w_hwmod_class = {
+ .name = hdq1w,
+ .sysc = am43xx_hdq1w_sysc,
+ .reset = omap_hdq1w_reset,
+};
+
+static struct omap_hwmod am43xx_hdq1w_hwmod = {
+ .name = hdq1w,
+ .class = am43xx_hdq1w_hwmod_class,
+ .clkdm_name = l4ls_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -790,6 +818,13 @@ static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_l4_ls__hdq1w = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_hdq1w_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -889,6 +924,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
+ am43xx_l4_ls__hdq1w,
NULL,
};
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index ad7b3e9977f8..48df3b55057e 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -143,5 +143,6 @@
#define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET0x0268
#define AM43XX_CM_PER_USBPHYOCP2SCP1_CLKCTRL_OFFSET0x05C0
#define AM43XX_CM_PER_DSS_CLKCTRL_OFFSET 0x0a20
+#define AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET 0x04a0
#endif
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] net: davinci_mdio: add hibernation callbacks
From: Grygorii Strashko grygorii.stras...@linaro.org
Setting a dev_pm_ops suspend_late/resume_early pair but not a
set of hibernation functions means those pm functions will
not be called upon hibernation.
Fix this by using SET_LATE_SYSTEM_SLEEP_PM_OPS, which appropriately
assigns the suspend and hibernation handlers and move
davinci_mdio_x callbacks under CONFIG_PM_SLEEP to avoid build warnings.
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/net/ethernet/ti/davinci_mdio.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c
b/drivers/net/ethernet/ti/davinci_mdio.c
index e58f0a7..25871dc 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -438,6 +438,7 @@ static int davinci_mdio_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
static int davinci_mdio_suspend(struct device *dev)
{
struct davinci_mdio_data *data = dev_get_drvdata(dev);
@@ -479,10 +480,10 @@ static int davinci_mdio_resume(struct device *dev)
return 0;
}
+#endif
static const struct dev_pm_ops davinci_mdio_pm_ops = {
- .suspend_late = davinci_mdio_suspend,
- .resume_early = davinci_mdio_resume,
+ SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
};
#if IS_ENABLED(CONFIG_OF)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] net: ti: cpsw: add hibernation callbacks
From: Grygorii Strashko grygorii.stras...@linaro.org
Setting a dev_pm_ops suspend/resume pair but not a set of
hibernation functions means those pm functions will not be
called upon hibernation.
Fix this by using SIMPLE_DEV_PM_OPS, which appropriately
assigns the suspend and hibernation handlers and move
cpsw_suspend/resume calbacks under CONFIG_PM_SLEEP
to avoid build warnings.
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/net/ethernet/ti/cpsw.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 8704954..b4fcf5f 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2805,6 +2805,7 @@ static int cpsw_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
static int cpsw_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -2857,11 +2858,9 @@ static int cpsw_resume(struct device *dev)
}
return 0;
}
+#endif
-static const struct dev_pm_ops cpsw_pm_ops = {
- .suspend= cpsw_suspend,
- .resume = cpsw_resume,
-};
+static SIMPLE_DEV_PM_OPS(cpsw_pm_ops, cpsw_suspend, cpsw_resume);
static const struct of_device_id cpsw_of_mtable[] = {
{ .compatible = ti,cpsw, },
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RESEND] usb: musb: fix Kconfig regression
Hi, On Sat, Feb 28, 2015 at 12:19:41AM +0100, Arnd Bergmann wrote: A recent bug fix I did that was marked for stable backports introduced a slightly wrong dependency on CONFIG_OMAP_CONTROL_PHY. I was missing the fact that the PHY driver already stubs out the omap_control_usb_set_mode, and we only need to add a dependency to prevent the musb-omap2430 driver from being built-in when the phy driver is a loadable module, but we should not prevent it from being built altogether when the phy driver is disabled. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: ca784be36cc725 (usb: start using the control module driver) Acked-by: Acked-by: Pavel Machek pa...@ucw.cz Cc: sta...@vger.kernel.org # v3.9+ This patch allows me to disable redundant CONFIG_OMAP_CONTROL_PHY from 4.0-rc1 .config and still get a working USB on Nokia N9. So: Tested-by: Aaro Koskinen aaro.koski...@iki.fi Thanks, A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH, RESEND] usb: musb: fix Kconfig regression
A recent bug fix I did that was marked for stable backports introduced a slightly wrong dependency on CONFIG_OMAP_CONTROL_PHY. I was missing the fact that the PHY driver already stubs out the omap_control_usb_set_mode, and we only need to add a dependency to prevent the musb-omap2430 driver from being built-in when the phy driver is a loadable module, but we should not prevent it from being built altogether when the phy driver is disabled. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: ca784be36cc725 (usb: start using the control module driver) Acked-by: Acked-by: Pavel Machek pa...@ucw.cz Cc: sta...@vger.kernel.org # v3.9+ --- Same patch as first time, now with correct recipient and with Pavel's Ack added. diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 14e1628483d9..39db8b603627 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -79,7 +79,8 @@ config USB_MUSB_TUSB6010 config USB_MUSB_OMAP2PLUS tristate OMAP2430 and onwards - depends on ARCH_OMAP2PLUS USB OMAP_CONTROL_PHY + depends on ARCH_OMAP2PLUS USB + depends on OMAP_CONTROL_PHY || !OMAP_CONTROL_PHY select GENERIC_PHY config USB_MUSB_AM35X -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] pinctrl: am33xx: dt-bindings: fix SLEWCTRL_FAST binding
According to AM335x TRM, Document spruh73l, Revised February 2015, Section 9.2.2 Pad Control Registers, setting bit 6 of the pad control registers actually sets the SLEWCTRL value to slow rather than fast as the current macro indicates. Introduce a new macro, SLEWCTRL_SLOW, that sets the bit, and modify SLEWCTRL_FAST to 0 but keep it for completeness. Current users of the macro (i2c and mdio) are left unmodified as SLEWCTRL_FAST was the macro used and actual desired state. Tested on am335x-gp-evm with no difference in software performance seen. Signed-off-by: Dave Gerlach d-gerl...@ti.com --- include/dt-bindings/pinctrl/am33xx.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/dt-bindings/pinctrl/am33xx.h b/include/dt-bindings/pinctrl/am33xx.h index 2fbc804..226f772 100644 --- a/include/dt-bindings/pinctrl/am33xx.h +++ b/include/dt-bindings/pinctrl/am33xx.h @@ -13,7 +13,8 @@ #define PULL_DISABLE (1 3) #define INPUT_EN (1 5) -#define SLEWCTRL_FAST (1 6) +#define SLEWCTRL_SLOW (1 6) +#define SLEWCTRL_FAST 0 /* update macro depending on INPUT_EN and PULL_ENA */ #undef PIN_OUTPUT -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] pinctrl: am43xx: dt-bindings: fix SLEWCTRL_FAST binding
According to AM437x TRM, Document SPRUHL7B, Revised December 2014, Section 7.2.1 Pad Control Registers, setting bit 19 of the pad control registers actually sets the SLEWCTRL value to slow rather than fast as the current macro indicates. Introduce a new macro, SLEWCTRL_SLOW, that sets the bit, and modify SLEWCTRL_FAST to 0 but keep it for completeness. Current users of the macro (i2c, mdio, and uart) are left unmodified as SLEWCTRL_FAST was the macro used and actual desired state. Tested on am437x-gp-evm with no difference in software performance seen. Signed-off-by: Dave Gerlach d-gerl...@ti.com --- include/dt-bindings/pinctrl/am43xx.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/dt-bindings/pinctrl/am43xx.h b/include/dt-bindings/pinctrl/am43xx.h index 9c2e4f8..5f4d0189 100644 --- a/include/dt-bindings/pinctrl/am43xx.h +++ b/include/dt-bindings/pinctrl/am43xx.h @@ -18,7 +18,8 @@ #define PULL_DISABLE (1 16) #define PULL_UP(1 17) #define INPUT_EN (1 18) -#define SLEWCTRL_FAST (1 19) +#define SLEWCTRL_SLOW (1 19) +#define SLEWCTRL_FAST 0 #define DS0_PULL_UP_DOWN_EN(1 27) #define PIN_OUTPUT (PULL_DISABLE) -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] pinctrl: dt-bindings: Fix amx3 SLEWCTRL_FAST binding
Currently both am33xx and am43xx have the macro for SLEWCTRL_FAST in pinctrl dt-bindings reversed so that selecting the macro actually sets SLEWCTRL_SLOW in the pad control registers. These patches correct the bindings but leave the pinctrl states that use the binding *UNMODIFIED*. Previously i2c and mdio on am33xx and i2c, mdio, and uart on am43xx had been using this macro and selecting SLEWCTRL_FAST while actually programming SLEWCTRL_SLOW in the pad config registers. Because the intended selection was SLEWCTRL_FAST the macros are unchanged. I tested on am335x-gp-evm and am437x-gp-evm with no difference in functionality seen. Regards, Dave Dave Gerlach (2): pinctrl: am33xx: dt-bindings: fix SLEWCTRL_FAST binding pinctrl: am43xx: dt-bindings: fix SLEWCTRL_FAST binding include/dt-bindings/pinctrl/am33xx.h | 3 ++- include/dt-bindings/pinctrl/am43xx.h | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] ARM OMAP2+ GPMC: add bus children
Hi Robert, On 26/02/15 16:45, Robert ABEL wrote: This patch adds support for spawning buses as children of the GPMC. Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de --- drivers/memory/omap-gpmc.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c index 5cabac8..74a8c52 100644 --- a/drivers/memory/omap-gpmc.c +++ b/drivers/memory/omap-gpmc.c @@ -27,6 +27,7 @@ #include linux/of_address.h #include linux/of_mtd.h #include linux/of_device.h +#include linux/of_platform.h #include linux/omap-gpmc.h #include linux/mtd/nand.h #include linux/pm_runtime.h @@ -1800,8 +1801,20 @@ static int gpmc_probe_generic_child(struct platform_device *pdev, gpmc_cs_enable_mem(cs); no_timings: - if (of_platform_device_create(child, NULL, pdev-dev)) - return 0; + + /* create platform device, NULL on error or when disabled */ + if (!of_platform_device_create(child, NULL, pdev-dev)) + goto err_child_fail; + + /* is child a common bus? */ + if (of_match_node(of_default_bus_match_table, child)) + /* create children and other common bus children */ + if (of_platform_populate(child, of_default_bus_match_table, NULL, pdev-dev)) + goto err_child_fail; this would print failed to create gpmc child but we have already created the gpmc child in the first of_platform_device_create() call. A more appropriate message would be failed to populate all children of child-name Also do you want to return failure? it will result in of_node_put() of the child and another print message about probing gpmc child %s failed in gpmc_probe_dt(). IMO if the GPMC node's child was created fine then we shouldn't return error. + + return 0; + +err_child_fail: dev_err(pdev-dev, failed to create gpmc child %s\n, child-name); ret = -ENODEV; cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] w1: masters: omap_hdq: Add support for 1-wire mode
Hi, On Friday 27 February 2015 03:25 PM, Arnd Bergmann wrote: On Friday 27 February 2015 14:54:17 Vignesh R wrote: +- compatible : should be ti,omap3-1w or ti,am43xx-hdq Do not use wildcards in the compatible string, use real part numbers if you don't know the actual name of the device. The DT node for hdq on AM437x is already present in mainline (commit: 741cac5f00beb) and it declares compatibility as ti,am43xx-hdq. Hence, I cannot change into anything different. Regards Vignesh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] w1: masters: omap_hdq: Add support for 1-wire mode
On Friday 27 February 2015 16:01:03 Vignesh R wrote: On Friday 27 February 2015 03:25 PM, Arnd Bergmann wrote: On Friday 27 February 2015 14:54:17 Vignesh R wrote: +- compatible : should be ti,omap3-1w or ti,am43xx-hdq Do not use wildcards in the compatible string, use real part numbers if you don't know the actual name of the device. The DT node for hdq on AM437x is already present in mainline (commit: 741cac5f00beb) and it declares compatibility as ti,am43xx-hdq. Hence, I cannot change into anything different. No, there is no driver using this device, and the binding was not documented, so there is no problem in changing it: nobody will notice a regression when it was never working before. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS
Robert,
On 26/02/15 16:45, Robert ABEL wrote:
DTS output was formatted to require additional work when copy-pasting into
DTS.
Nano-second timings were replaced with interval of values that produce the
same
number of clock ticks.
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
---
drivers/memory/omap-gpmc.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index dbb6753..9340e7a 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -337,32 +337,49 @@ static void gpmc_cs_bool_timings(int cs, const struct
gpmc_bool_timings *p)
}
#ifdef DEBUG
+/**
+ * get_gpmc_timing_reg - read a timing parameter and print DTS settings for
it.
+ * @cs Chip Select Region
+ * @reg GPMC_CS_CONFIGn register offset.
+ * @st_bit Start Bit
+ * @end_bit End Bit. Must be = @st_bit.
+ * @nameDTS node name, w/o gpmc,
+ * @raw Raw Format Option.
+ * raw format: gpmc,name = value
+ * tick format: gpmc,name = value /zwj;*(x ns -- y ns]; x ticks
*zwj;/
+ * Where (x ns -- y ns] is the half-open interval from x ns to y ns
that
+ * result in the same tick value.
+ * @noval Parameter values equal to 0 are not printed.
+ * @shift Parameter value left shifts @shift, which is then printed
instead of value.
+ *
+ */
static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
bool raw, bool noval, int shift,
const char *name)
{
u32 l;
- int nr_bits, max_value, mask;
+ int nr_bits;
+ int mask;
l = gpmc_cs_read_reg(cs, reg);
nr_bits = end_bit - st_bit + 1;
- max_value = (1 nr_bits) - 1;
- mask = max_value st_bit;
- l = (l mask) st_bit;
+ mask = (1 nr_bits) - 1;
+ l = (l st_bit) mask;
if (shift)
l = (shift l);
if (noval (l == 0))
return 0;
if (!raw) {
- unsigned int time_ns_min, time_ns, time_ns_max;
+ /* DTS tick format for timings in ns */
+ unsigned int time_ns;
+ unsigned int time_ns_min;
time_ns_min = gpmc_ticks_to_ns(l ? l - 1 : 0);
should be
time_ns_min = l ? gpmc_ticks_to_ns(l - 1) + 1 : 0;
+ 1ns since we don't want to fall into the previous tick
bracket.
for l == 0 we have t_min as 0. no need to pass it through
gpmc_ticks_to_ns() or add 1 ns.
time_ns = gpmc_ticks_to_ns(l);
- time_ns_max = gpmc_ticks_to_ns(l + 1 max_value ?
-max_value : l + 1);
- pr_info(gpmc,%s = %u (%u - %u ns, %i ticks)\n,
- name, time_ns, time_ns_min, time_ns_max, l);
+ pr_info(gpmc,%s = %u /* (%u ns - %u ns]; %i ticks */\n,
+ name, time_ns, time_ns_min, time_ns, l);
} else {
+ /* raw format */
pr_info(gpmc,%s = %u\n, name, l);
}
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] w1: masters: omap_hdq: Add support for 1-wire mode
On Friday 27 February 2015 14:54:17 Vignesh R wrote: +- compatible : should be ti,omap3-1w or ti,am43xx-hdq Do not use wildcards in the compatible string, use real part numbers if you don't know the actual name of the device. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: fix Kconfig regression
On Fri 2015-02-27 21:12:45, Arnd Bergmann wrote: A recent bug fix I did that was marked for stable backports introduced a slightly wrong dependency on CONFIG_OMAP_CONTROL_PHY. I was missing the fact that the PHY driver already stubs out the omap_control_usb_set_mode, and we only need to add a dependency to prevent the musb-omap2430 driver from being built-in when the phy driver is a loadable module, but we should not prevent it from being built altogether when the phy driver is disabled. This changes the dependency to allow OMAP_CONTROL_PHY to be disabled, but to disallow USB_MUSB_OMAP2PLUS from being built-in if OMAP_CONTROL_PHY is a loadable module. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: ca784be36cc725 (usb: start using the control module driver) Cc: sta...@vger.kernel.org # v3.9+ Cc: Felipe Balbi ba...@ti.com Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: omap_hsmmc: add hibernation support
From: Russ Dill russ.d...@ti.com
Setting a dev_pm_ops suspend/resume pair but not a set of
hibernation functions means those pm functions will not be
called upon hibernation.
Fix this by using SET_SYSTEM_SLEEP_PM_OPS, which appropriately
assigns the suspend and hibernation handlers and move
omap_hsmmc_x callbacks under CONFIG_PM_SLEEP to avoid build warnings.
Signed-off-by: Russ Dill russ.d...@ti.com
[grygorii.stras...@linaro.org: rebased on top of K4.0]
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
original patch:
https://github.com/russdill/linux/commit/2ea98def0717f0918426c2004122c63d52cff1b4
drivers/mmc/host/omap_hsmmc.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f84cfb0..9cc1ea3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2236,7 +2236,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int omap_hsmmc_suspend(struct device *dev)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -2292,10 +2292,6 @@ static int omap_hsmmc_resume(struct device *dev)
pm_runtime_put_autosuspend(host-dev);
return 0;
}
-
-#else
-#define omap_hsmmc_suspend NULL
-#define omap_hsmmc_resume NULL
#endif
static int omap_hsmmc_runtime_suspend(struct device *dev)
@@ -2376,8 +2372,7 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
}
static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
- .suspend= omap_hsmmc_suspend,
- .resume = omap_hsmmc_resume,
+ SET_SYSTEM_SLEEP_PM_OPS(omap_hsmmc_suspend, omap_hsmmc_resume)
.runtime_suspend = omap_hsmmc_runtime_suspend,
.runtime_resume = omap_hsmmc_runtime_resume,
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/21] drm/omap: check CRTC color format earlier
On Thu, Feb 26, 2015 at 03:20:14PM +0200, Tomi Valkeinen wrote:
When setting a color format to a DRM plane, the DRM core checks whether
the format is supported by the HW. However, it seems that when setting
the color format of a CRTC (i.e. a root plane), there's no checking
done. This causes omapdrm to configure omapdss with the bad color
format, which omapdss then rejects.
While the above is ok, the error message is a bit confusing, and the
configuring of omapdss happens asynchronously from the ioctl that does
the color format change.
This patch adds a color format check to omap_plane_mode_set() which
causes the ioctl to return an error for invalid color format. This means
that the userspace will get to know of the wrong setting, instead of the
current behavior where the error is not seen by the userspace.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_plane.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 1f4f2b866379..bedd6f7af0f1 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -207,6 +207,24 @@ int omap_plane_mode_set(struct drm_plane *plane,
{
struct omap_plane *omap_plane = to_omap_plane(plane);
struct omap_drm_window *win = omap_plane-win;
+ int i;
+
+ /*
+ * Check whether this plane supports the fb pixel format.
+ * I don't think this should really be needed, but it looks like the
+ * drm core only checks the format for planes, not for the crtc. So
+ * when setting the format for crtc, without this check we would
+ * get an error later when trying to program the color format into the
+ * HW.
+ */
I think we should add a format check to the setcrtc ioctl if crtc-primary
is set. Atm the code is in __setplane_internal but could easily be shared
- there's already a copy in drm_atomi.c.
Omapdrm wouldn't benefit from this yet since it doesn't support universal
planes. But adding universal planes should be on your todo anyway ;-)
-Daniel
+ for (i = 0; i plane-format_count; i++)
+ if (fb-pixel_format == plane-format_types[i])
+ break;
+ if (i == plane-format_count) {
+ DBG(Invalid pixel format %s,
+ drm_get_format_name(fb-pixel_format));
+ return -EINVAL;
+ }
win-crtc_x = crtc_x;
win-crtc_y = crtc_y;
--
2.3.0
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
