Re: tfp410 and i2c_bus_num
Hi, On Sat, Nov 17, 2012 at 07:41:36AM +0200, Tomi Valkeinen wrote: On 2012-11-16 20:21, Felipe Balbi wrote: Hi, On Fri, Nov 16, 2012 at 05:39:44PM +0200, Tomi Valkeinen wrote: To be fair, the whole i2c_bus_num looks like a big hackery introduced by the way panel drivers are written for OMAP DSS. TFP410 is an I2C client, not an OMAPDSS client. After a quick look at the driver, there's is no such thing as a DSS bus, so looks like you should have an I2C driver for TFP410 and the whole DSS stuff should be just a list of clients, but not a struct bus at all. The fact that you have to pass the I2C bus number down to the panel driver is already a big indication of how wrong this is, IMHO. Without going deeper in the dss device model problems, I would agree with you if this was about i2c panel, but this is not quite like that. A panel controlled via i2c would be an i2c device. But TFP410 is not controlled via i2c. It's not really controlled at all except via power-down gpio. TFP410 doesn't need the i2c to be functional at all. then why does it need the i2c adapter ? What is this power-down gpio ? Should that be hidden under gpiolib instead ? For the i2c, see below. Power-down GPIO is used to power down and up the tfp410 chip. that much I guessed ;-) Should it be hidden under gpiolib ? I have to say I have no idea what you mean... Hidden how? how are you toggling the gpio ? You said tfp410 isn't controlled at all except for the power down gpio. Who provides the gpio ? The i2c lines do not even touch TFP410 chip, so to be precise, the i2c lines should not be TFP410's concern. The i2c lines come from the monitor and go to OMAP's i2c pins. But TFP410 driver is a convenient place to manage them. fair enough... but who's actually using those i2c lines ? OMAP is the I2C master, who's the slave ? It's something in the monitor, I assume... IIUC, this I2C bus goes over the HDMI wire ? Yes, the i2c goes over HDMI wire. OMAP is the master, monitor is the slave. You can see some more info from http://en.wikipedia.org/wiki/Display_Data_Channel under DDC2 section. It is used to read the EDID (http://en.wikipedia.org/wiki/Extended_display_identification_data) information from the monitor, which tells things like supported video timings etc. As for why the tfp410 driver handles the i2c... We don't have a better place. There's no driver for the monitor. Although in the future with than that's wrong :-) If TFP410 isn't really using I2C it shouldn't need the whole i2c_bus_num logic. I'm far from fully understanding dss architecture but it looks like what you want is a generic 'i2c-edid.c' which just reads the edid structure during probe and caches the values and exposes them via sysfs ?!? (perhaps you also need a kernel API to read those values... I don't know; but that's also doable). Well, it's not that simple. TFP410 manages hot plug detection of the HDMI cable (although not implemented currently), so the we'd need to convey that information to the i2c-edid somehow. Which, of course, is doable, but increases complexity. I'd say it would decrease it since you would have a single copy of i2c-edid.c for DRM or DSS or any other panel/display framework. Another thing is that even if in this case the i2c and EDID reading are separate from the actual video path, that may not be the case for other display solutions. We could have a DSI panel which reports its resolution via DSI bus, or we could have an external DSI-to-HDMI chip, which reads the EDID via i2c from the monitor, but reports them back to the SoC via DSI bus. In this last case we would see just the DSI, not the I2C bus, so it's like I2C bus doesn't exist, so in fact we would have two possibilities: a) read EDID via I2C bus (standard HDMI) b) read EDID via DSI. b) doesn't exist today so we need to care about it until something like what you say shows up in the market. Until then, we care for EDID over I2C IMHO. So we need a generic way to get the resolution information, and it makes sense to have this in the components of the video path, not in a separate driver which is not part of the video path as such. But the I2C bus isn't part of the video path anyway. It's a completely separate path which is dedicated to reading EDID. If you need a generic way for that case you wanna cope with other methods for reading EDID, then you need a generic layer which doesn't care if it's I2C or DSI. Currently implementation is hardcoded to I2C anyway. In fact current implementation is far worse than having an extra i2c-edid.c driver because it doesn't encapsulate EDID implementation from tfp410. Then moment you need to read EDID via DSI, you will likely have to pass a DSI handle to e.g. TFP410 so it can read EDID via DSI. What I'm suggesting, however, is that you have a layer hiding all that. Make your i2c-edid.c driver read EDID and report it to
[PATCH 2/2] ARM: OMAP3: cm-t3517: use GPTIMER for system clock
cm-t3517 starting from revision 1.2 does not have the 32K oscilator wired to the AM3517 SoC. Therefore switch to use the GPTIMER for system clock. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/timer.c |3 +++ 3 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-cm-t3517.c b/arch/arm/mach-omap2/board-cm-t3517.c index 699caec..ebbc2ad 100644 --- a/arch/arm/mach-omap2/board-cm-t3517.c +++ b/arch/arm/mach-omap2/board-cm-t3517.c @@ -297,6 +297,6 @@ MACHINE_START(CM_T3517, Compulab CM-T3517) .handle_irq = omap3_intc_handle_irq, .init_machine = cm_t3517_init, .init_late = am35xx_init_late, - .timer = omap3_timer, + .timer = omap3_gp_timer, .restart= omap3xxx_restart, MACHINE_END diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index dae55d8..948bcaa 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -82,6 +82,7 @@ extern void omap2_init_common_infrastructure(void); extern struct sys_timer omap2_timer; extern struct sys_timer omap3_timer; extern struct sys_timer omap3_secure_timer; +extern struct sys_timer omap3_gp_timer; extern struct sys_timer omap3_am33xx_timer; extern struct sys_timer omap4_timer; extern struct sys_timer omap5_timer; diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 418753f..4bcf080 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -596,6 +596,9 @@ OMAP_SYS_TIMER(3, sync32k); OMAP_SYS_32K_TIMER_INIT(3_secure, 12, OMAP3_32K_SOURCE, ti,timer-secure, 2, OMAP3_MPU_SOURCE); OMAP_SYS_TIMER(3_secure, sync32k); +OMAP_SYS_GP_TIMER_INIT(3_gp, 1, OMAP3_MPU_SOURCE, ti,timer-alwon, + 2, OMAP3_MPU_SOURCE); +OMAP_SYS_TIMER(3_gp, gptimer); #endif /* CONFIG_ARCH_OMAP3 */ #ifdef CONFIG_SOC_AM33XX -- 1.7.3.4 -- 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 v2 1/2] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
setting.
To remove the dependancy, several conversions/additions had to be done:
1) Timer initialization functions are named by the platform
name and the clock source in use.
This also makes it possible to define and use the GPTIMER as the
clock source instead of the 32K timer on platforms that do not have
the 32K timer ip block or the 32K timer is not wired on the board.
Cirrently, the the timer is chosen in the machine_desc structure on
per board basis. Later, DT should be used to choose the timer.
2) Settings under the CONFIG_OMAP_32K_TIMER option are used as defaults
and those under !CONFIG_OMAP_32K_TIMER are removed.
This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
3) Since we have all the timers defined inside machine_desc structure
and we no longer need the fallback to gp_timer clock source in case
32k_timer clock source is unavailable (namely on AM33xx), we no
longer need the #ifdef around __omap2_sync32k_clocksource_init()
function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
__omap2_sync32k_clocksource_init() function.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Jon Hunter jon-hun...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
---
Compile tested on omap2plus_defconfig + crane board enabled.
This patch conflicts slightly with the:
ARM: OMAP2+: Fix compiler warning for 32k timer (From Jon)
(or its future versions) available at:
http://www.spinics.net/lists/linux-omap/msg82465.html
With this patch applied, there will be no need for the above patch.
v2: 1) Do not change the default timer name to avoid multiple
renaming in the board files (Tony).
2) Inline the DT timer property (Jon).
3) Do not rename actual timer initialization functions and get rid of the
wrapper function for omap2_sync32k_clocksource_init() function.
4) Remove the oddness around omap2_##clksrc_name##_clocksource_init()
function by introducing a separate macro for gptimer case.
5) Avoid having two timer_init functions for each OMAP generation and
add only those necessary (Jon).
arch/arm/mach-omap2/timer.c | 128 +-
arch/arm/plat-omap/Kconfig |6 ++
2 files changed, 58 insertions(+), 76 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 099e406..418753f 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -64,20 +64,6 @@
#define OMAP3_32K_SOURCE omap_32k_fck
#define OMAP4_32K_SOURCE sys_32k_ck
-#ifdef CONFIG_OMAP_32K_TIMER
-#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
-#define OMAP3_SECURE_TIMER 12
-#define TIMER_PROP_SECURE ti,timer-secure
-#else
-#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
-#define OMAP3_SECURE_TIMER 1
-#define TIMER_PROP_SECURE ti,timer-alwon
-#endif
-
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
@@ -407,7 +393,6 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
}
-#ifdef CONFIG_OMAP_32K_TIMER
/* Setup free-running counter for clocksource */
static int __init omap2_sync32k_clocksource_init(void)
{
@@ -468,12 +453,6 @@ static int __init omap2_sync32k_clocksource_init(void)
return ret;
}
-#else
-static inline int omap2_sync32k_clocksource_init(void)
-{
- return -ENODEV;
-}
-#endif
static void __init omap2_gptimer_clocksource_init(int gptimer_id,
const char *fck_source)
@@ -499,25 +478,6 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
gptimer_id, clksrc.rate);
}
-static void __init omap2_clocksource_init(int gptimer_id,
- const char *fck_source)
-{
- /*
-* First give preference to kernel parameter configuration
-* by user (clocksource=gp_timer).
-*
-* In case of missing kernel parameter for clocksource,
-* first check for availability for 32k-sync timer, in case
-* of failure in finding 32k_counter module or registering
-* it as clocksource, execution will fallback to gp-timer.
-*/
- if (use_gptimer_clksrc == true)
- omap2_gptimer_clocksource_init(gptimer_id, fck_source);
- else if (omap2_sync32k_clocksource_init())
- /* Fall back to gp-timer code */
- omap2_gptimer_clocksource_init(gptimer_id, fck_source);
-}
-
#ifdef
[PATCH 0/7] ir-rx51: Various fixes
Hi,
Here is a set of fixes that did not make in the last merge
window. Everything else except the last patch that fixes sparse
complaints have been posted before.
Especially the PM QoS conversion patch is important, without that one
the driver does not work at all unless there is some background load
keeping the CPU from sleeping.
The signal handling fixup patches did raise all sorts of discussion
last time, but my conclusion was that the patch itself should be fine
for now.
Please provide feedback and consider accepting them in. Thank you.
Timo Kokkonen (7):
ir-rx51: Handle signals properly
ir-rx51: Clean up timer initialization code
ir-rx51: Move platform data checking into probe function
ir-rx51: Replace module_{init,exit} macros with
module_platform_driver
ir-rx51: Convert latency constraints to PM QoS API
ir-rx51: Remove useless variable from struct lirc_rx51
ir-rx51: Fix sparse warnings
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 -
drivers/media/rc/ir-rx51.c | 108 ++-
include/media/ir-rx51.h | 2 -
3 files changed, 56 insertions(+), 56 deletions(-)
--
1.8.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/7] ir-rx51: Clean up timer initialization code
Remove a redundant macro definition. This is unneeded and becomes more
readable once the actual timer code is refactored a little.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 125d4c3..f22e5e4 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -105,11 +105,9 @@ static int init_timing_params(struct lirc_rx51 *lirc_rx51)
return 0;
}
-#define tics_after(a, b) ((long)(b) - (long)(a) 0)
-
static int pulse_timer_set_timeout(struct lirc_rx51 *lirc_rx51, int usec)
{
- int counter;
+ int counter, counter_now;
BUG_ON(usec 0);
@@ -122,11 +120,8 @@ static int pulse_timer_set_timeout(struct lirc_rx51
*lirc_rx51, int usec)
omap_dm_timer_set_match(lirc_rx51-pulse_timer, 1, counter);
omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer,
OMAP_TIMER_INT_MATCH);
- if (tics_after(omap_dm_timer_read_counter(lirc_rx51-pulse_timer),
- counter)) {
- return 1;
- }
- return 0;
+ counter_now = omap_dm_timer_read_counter(lirc_rx51-pulse_timer);
+ return (counter - counter_now) 0;
}
static irqreturn_t lirc_rx51_interrupt_handler(int irq, void *ptr)
--
1.8.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/7] ir-rx51: Fix sparse warnings
Add missing __user annotation to all of the user space memory
accesses. Otherwise sparse is complainign about address space
difference in types.
Also struct lirc_rx51_platform_driver is missing static keyword even
though it should have it.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index edb1562..7ed0616 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -233,7 +233,7 @@ static int lirc_rx51_free_port(struct lirc_rx51 *lirc_rx51)
return 0;
}
-static ssize_t lirc_rx51_write(struct file *file, const char *buf,
+static ssize_t lirc_rx51_write(struct file *file, const char __user *buf,
size_t n, loff_t *ppos)
{
int count, i;
@@ -308,13 +308,13 @@ static long lirc_rx51_ioctl(struct file *filep,
switch (cmd) {
case LIRC_GET_SEND_MODE:
- result = put_user(LIRC_MODE_PULSE, (unsigned long *)arg);
+ result = put_user(LIRC_MODE_PULSE, (unsigned long __user *)arg);
if (result)
return result;
break;
case LIRC_SET_SEND_MODE:
- result = get_user(value, (unsigned long *)arg);
+ result = get_user(value, (unsigned long __user *)arg);
if (result)
return result;
@@ -324,7 +324,7 @@ static long lirc_rx51_ioctl(struct file *filep,
break;
case LIRC_GET_REC_MODE:
- result = put_user(0, (unsigned long *) arg);
+ result = put_user(0, (unsigned long __user *)arg);
if (result)
return result;
break;
@@ -334,7 +334,7 @@ static long lirc_rx51_ioctl(struct file *filep,
break;
case LIRC_SET_SEND_DUTY_CYCLE:
- result = get_user(ivalue, (unsigned int *) arg);
+ result = get_user(ivalue, (unsigned int __user *)arg);
if (result)
return result;
@@ -348,7 +348,7 @@ static long lirc_rx51_ioctl(struct file *filep,
break;
case LIRC_SET_SEND_CARRIER:
- result = get_user(ivalue, (unsigned int *) arg);
+ result = get_user(ivalue, (unsigned int __user *)arg);
if (result)
return result;
@@ -363,7 +363,7 @@ static long lirc_rx51_ioctl(struct file *filep,
case LIRC_GET_FEATURES:
result = put_user(LIRC_RX51_DRIVER_FEATURES,
- (unsigned long *) arg);
+ (unsigned long __user *)arg);
if (result)
return result;
break;
@@ -484,7 +484,7 @@ static int __exit lirc_rx51_remove(struct platform_device
*dev)
return lirc_unregister_driver(lirc_rx51_driver.minor);
}
-struct platform_driver lirc_rx51_platform_driver = {
+static struct platform_driver lirc_rx51_platform_driver = {
.probe = lirc_rx51_probe,
.remove = __exit_p(lirc_rx51_remove),
.suspend= lirc_rx51_suspend,
--
1.8.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/7] ir-rx51: Handle signals properly
The lirc-dev expects the ir-code to be transmitted when the write call
returns back to the user space. We should not leave TX ongoing no
matter what is the reason we return to the user space. Easiest
solution for that is to simply remove interruptible sleeps.
The first wait_event_interruptible is thus replaced with return -EBUSY
in case there is still ongoing transfer. This should suffice as the
concept of sending multiple codes in parallel does not make sense.
The second wait_event_interruptible call is replaced with
wait_even_timeout with a fixed and safe timeout that should prevent
the process from getting stuck in kernel for too long.
Also, from now on we will force the TX to stop before we return from
write call. If the TX happened to time out for some reason, we should
not leave the HW transmitting anything.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 546199e..125d4c3 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
OMAP_TIMER_TRIGGER_NONE);
}
+static void lirc_rx51_stop_tx(struct lirc_rx51 *lirc_rx51)
+{
+ if (lirc_rx51-wbuf_index 0)
+ return;
+
+ lirc_rx51_off(lirc_rx51);
+ lirc_rx51-wbuf_index = -1;
+ omap_dm_timer_stop(lirc_rx51-pwm_timer);
+ omap_dm_timer_stop(lirc_rx51-pulse_timer);
+ omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
+ wake_up(lirc_rx51-wqueue);
+}
+
static int init_timing_params(struct lirc_rx51 *lirc_rx51)
{
u32 load, match;
@@ -163,13 +176,7 @@ static irqreturn_t lirc_rx51_interrupt_handler(int irq,
void *ptr)
return IRQ_HANDLED;
end:
- /* Stop TX here */
- lirc_rx51_off(lirc_rx51);
- lirc_rx51-wbuf_index = -1;
- omap_dm_timer_stop(lirc_rx51-pwm_timer);
- omap_dm_timer_stop(lirc_rx51-pulse_timer);
- omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
- wake_up_interruptible(lirc_rx51-wqueue);
+ lirc_rx51_stop_tx(lirc_rx51);
return IRQ_HANDLED;
}
@@ -249,8 +256,9 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
if ((count WBUF_LEN) || (count % 2 == 0))
return -EINVAL;
- /* Wait any pending transfers to finish */
- wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
+ /* We can have only one transmit at a time */
+ if (lirc_rx51-wbuf_index = 0)
+ return -EBUSY;
if (copy_from_user(lirc_rx51-wbuf, buf, n))
return -EFAULT;
@@ -276,9 +284,18 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
/*
* Don't return back to the userspace until the transfer has
-* finished
+* finished. However, we wish to not spend any more than 500ms
+* in kernel. No IR code TX should ever take that long.
+*/
+ i = wait_event_timeout(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0,
+ HZ / 2);
+
+ /*
+* Ensure transmitting has really stopped, even if the timers
+* went mad or something else happened that caused it still
+* sending out something.
*/
- wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
+ lirc_rx51_stop_tx(lirc_rx51);
/* We can sleep again */
lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, -1);
--
1.8.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 6/7] ir-rx51: Remove useless variable from struct lirc_rx51
As clearly visible from the patch, this variable has no useful purpose
what so ever. Thus, it can be removed altogether without any side
effects.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 96ed23d..edb1562 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -57,7 +57,6 @@ struct lirc_rx51 {
unsigned intfreq; /* carrier frequency */
unsigned intduty_cycle; /* carrier duty cycle */
unsigned intirq_num;
- unsigned intmatch;
int wbuf[WBUF_LEN];
int wbuf_index;
unsigned long device_is_open;
@@ -102,8 +101,6 @@ static int init_timing_params(struct lirc_rx51 *lirc_rx51)
omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer, 0);
omap_dm_timer_start(lirc_rx51-pulse_timer);
- lirc_rx51-match = 0;
-
return 0;
}
@@ -113,11 +110,7 @@ static int pulse_timer_set_timeout(struct lirc_rx51
*lirc_rx51, int usec)
BUG_ON(usec 0);
- if (lirc_rx51-match == 0)
- counter = omap_dm_timer_read_counter(lirc_rx51-pulse_timer);
- else
- counter = lirc_rx51-match;
-
+ counter = omap_dm_timer_read_counter(lirc_rx51-pulse_timer);
counter += (u32)(lirc_rx51-fclk_khz * usec / (1000));
omap_dm_timer_set_match(lirc_rx51-pulse_timer, 1, counter);
omap_dm_timer_set_int_enable(lirc_rx51-pulse_timer,
--
1.8.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/7] ir-rx51: Move platform data checking into probe function
This driver is useless without proper platform data. If data is not
available, we should not register the driver at all. Once this check
is done, the BUG_ON check during device open is no longer needed.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index f22e5e4..16b3c1f 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -378,7 +378,6 @@ static long lirc_rx51_ioctl(struct file *filep,
static int lirc_rx51_open(struct inode *inode, struct file *file)
{
struct lirc_rx51 *lirc_rx51 = lirc_get_pdata(file);
- BUG_ON(!lirc_rx51);
file-private_data = lirc_rx51;
@@ -458,6 +457,9 @@ static int lirc_rx51_resume(struct platform_device *dev)
static int __devinit lirc_rx51_probe(struct platform_device *dev)
{
+ if (!dev-dev.platform_data)
+ return -ENODEV;
+
lirc_rx51_driver.features = LIRC_RX51_DRIVER_FEATURES;
lirc_rx51.pdata = dev-dev.platform_data;
lirc_rx51.pwm_timer_num = lirc_rx51.pdata-pwm_timer;
--
1.8.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 5/7] ir-rx51: Convert latency constraints to PM QoS API
Convert the driver from the obsolete omap_pm_set_max_mpu_wakeup_lat
API to the new PM QoS API. This allows the callback to be removed from
the platform data structure.
The latency requirements are also adjusted to prevent the MPU from
going into sleep mode. This is needed as the GP timers have no means
to wake up the MPU once it has gone into sleep. The side effect is
that from now on the driver actually works even if there is no
background load keeping the MPU awake.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 --
drivers/media/rc/ir-rx51.c | 17 -
include/media/ir-rx51.h | 2 --
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 020e03c..6d0f29d 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -33,7 +33,6 @@
#include common.h
#include plat/dma.h
#include plat/gpmc.h
-#include plat/omap-pm.h
#include gpmc-smc91x.h
#include board-rx51.h
@@ -1224,7 +1223,6 @@ static void __init rx51_init_tsc2005(void)
#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
static struct lirc_rx51_platform_data rx51_lirc_data = {
- .set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
.pwm_timer = 9, /* Use GPT 9 for CIR */
};
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 6e1ffa6..96ed23d 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -25,6 +25,7 @@
#include linux/platform_device.h
#include linux/sched.h
#include linux/wait.h
+#include linux/pm_qos.h
#include plat/dmtimer.h
#include plat/clock.h
@@ -49,6 +50,7 @@ struct lirc_rx51 {
struct omap_dm_timer *pulse_timer;
struct device*dev;
struct lirc_rx51_platform_data *pdata;
+ struct pm_qos_request pm_qos_request;
wait_queue_head_t wqueue;
unsigned long fclk_khz;
@@ -268,10 +270,16 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
lirc_rx51-wbuf[count] = -1; /* Insert termination mark */
/*
-* Adjust latency requirements so the device doesn't go in too
-* deep sleep states
+* If the MPU is going into too deep sleep state while we are
+* transmitting the IR code, timers will not be able to wake
+* up the MPU. Thus, we need to set a strict enough latency
+* requirement in order to ensure the interrupts come though
+* properly. The 10us latency requirement is low enough to
+* keep MPU from sleeping and thus ensures the interrupts are
+* getting through properly.
*/
- lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, 50);
+ pm_qos_add_request(lirc_rx51-pm_qos_request,
+ PM_QOS_CPU_DMA_LATENCY, 10);
lirc_rx51_on(lirc_rx51);
lirc_rx51-wbuf_index = 1;
@@ -292,8 +300,7 @@ static ssize_t lirc_rx51_write(struct file *file, const
char *buf,
*/
lirc_rx51_stop_tx(lirc_rx51);
- /* We can sleep again */
- lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, -1);
+ pm_qos_remove_request(lirc_rx51-pm_qos_request);
return n;
}
diff --git a/include/media/ir-rx51.h b/include/media/ir-rx51.h
index 104aa89..57523f2 100644
--- a/include/media/ir-rx51.h
+++ b/include/media/ir-rx51.h
@@ -3,8 +3,6 @@
struct lirc_rx51_platform_data {
int pwm_timer;
-
- int(*set_max_mpu_wakeup_lat)(struct device *dev, long t);
};
#endif
--
1.8.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 4/7] ir-rx51: Replace module_{init,exit} macros with module_platform_driver
No reason to avoid using the existing helpers.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/ir-rx51.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 16b3c1f..6e1ffa6 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -495,17 +495,7 @@ struct platform_driver lirc_rx51_platform_driver = {
},
};
-static int __init lirc_rx51_init(void)
-{
- return platform_driver_register(lirc_rx51_platform_driver);
-}
-module_init(lirc_rx51_init);
-
-static void __exit lirc_rx51_exit(void)
-{
- platform_driver_unregister(lirc_rx51_platform_driver);
-}
-module_exit(lirc_rx51_exit);
+module_platform_driver(lirc_rx51_platform_driver);
MODULE_DESCRIPTION(LIRC TX driver for Nokia RX51);
MODULE_AUTHOR(Nokia Corporation);
--
1.8.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
TPS65217 declarations is missed in omap2defconfig
Hello, TPS65217 is described in the arch/arm/boot/dts/AM335x-bone.dts file but not declared in the arch/arm/configs/omap2plus_defconfig. Is it a known issue? Should I send a patch to fix it? Regards, Igor. -- 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 v4 0/4] cbus/retu drivers
This patch set introduces drivers for CBUS access and Retu multifunction chip found on Nokia Internet Tablets (770, N800, N810). It would be nice get these patches applied as the functionality of these devices is severely lacking without Retu. E.g. watchdog support is mandatory at least on Nokia N800, you cannot currently run the mainline kernel for longer than ~60 seconds (there is no way to disable the watchdog). Drivers originate from linux-omap cbus branch and have been cleaned up/rewritten around i2c and MFD core. Patches have been tested on top of 3.7-rc6 with Nokia N800 (watchdog feeding works, power off shuts down the device, power button triggers IRQs and input events, loading and unloading retu-pwrbutton module in a loop while manically pressing the power button does not crash the kernel). Changes since the third version (https://lkml.org/lkml/2012/11/12/338): - i2c-cbus-gpio: - driver renamed (i2c-cbus - i2c-cbus-gpio) - added Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt Changes since the second version (https://lkml.org/lkml/2012/10/31/520): - i2c-cbus: - move i2c-cbus.h under linux/platform_data - retu-mfd - replace retu_pwrbutton_res[0] expression with simpler retu_pwrbutton_res. - retu-pwrbutton: - eliminate struct retu_pwrbutton - delete checks for duplicate events - rework probe to avoid races - disable IRQ before unregister in retu_pwrbutton_remove() to avoid races - eliminate double free in retu_pwrbutton_remove() - add .owner = THIS_MODULE Changes since the first version (https://lkml.org/lkml/2012/9/3/265): - i2c-cbus: - use devres - improve comments - simplify and delete redundant code - refactoring bug fixes on error handling - discard input parameter from cbus_send_bit/data() - retu-mfd: - use devres - use regmap - retu_wdt: use devres - retu-pwrbutton: use devres Changes since the RFC version (http://marc.info/?l=linux-omapm=134618967116737w=2): - added DT support for getting i2c-cbus GPIO pins - merged n8x0 board file changes into i2c-cbus patch - corrected typo in Kconfig for MFD_RETU - added power off functionality to retu-mfd - added IRQ functionality to retu-mfd - added power button key driver - some cleanups Aaro Koskinen (4): i2c: introduce i2c-cbus-gpio driver mfd: introduce retu-mfd driver watchdog: introduce retu_wdt driver input: misc: introduce retu-pwrbutton .../devicetree/bindings/i2c/i2c-cbus-gpio.txt | 27 ++ arch/arm/mach-omap2/board-n8x0.c | 42 +++ drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile|1 + drivers/i2c/busses/i2c-cbus-gpio.c | 300 drivers/input/misc/Kconfig | 10 + drivers/input/misc/Makefile|1 + drivers/input/misc/retu-pwrbutton.c| 102 +++ drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |1 + drivers/mfd/retu-mfd.c | 264 + drivers/watchdog/Kconfig | 12 + drivers/watchdog/Makefile |1 + drivers/watchdog/retu_wdt.c| 178 include/linux/mfd/retu.h | 22 ++ include/linux/platform_data/i2c-cbus-gpio.h| 27 ++ 16 files changed, 1007 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt create mode 100644 drivers/i2c/busses/i2c-cbus-gpio.c create mode 100644 drivers/input/misc/retu-pwrbutton.c create mode 100644 drivers/mfd/retu-mfd.c create mode 100644 drivers/watchdog/retu_wdt.c create mode 100644 include/linux/mfd/retu.h create mode 100644 include/linux/platform_data/i2c-cbus-gpio.h -- 1.7.10.4 -- 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 v4 2/4] mfd: introduce retu-mfd driver
Retu is a multi-function device found on Nokia Internet Tablets
implementing at least watchdog, RTC, headset detection and power button
functionality.
This patch implements minimum functionality providing register access,
IRQ handling and power off functions.
Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/mfd/Kconfig |9 ++
drivers/mfd/Makefile |1 +
drivers/mfd/retu-mfd.c | 264 ++
include/linux/mfd/retu.h | 22
4 files changed, 296 insertions(+)
create mode 100644 drivers/mfd/retu-mfd.c
create mode 100644 include/linux/mfd/retu.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index acab3ef..7528c5e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1044,6 +1044,15 @@ config MFD_PALMAS
If you say yes here you get support for the Palmas
series of PMIC chips from Texas Instruments.
+config MFD_RETU
+ tristate Support for Retu multi-function device
+ select MFD_CORE
+ depends on I2C
+ select REGMAP_IRQ
+ help
+ Retu is a multi-function device found on Nokia Internet Tablets
+ (770, N800 and N810).
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d8ccb63..ad7879f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -138,3 +138,4 @@ obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
+obj-$(CONFIG_MFD_RETU) += retu-mfd.o
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
new file mode 100644
index 000..7ff4a37
--- /dev/null
+++ b/drivers/mfd/retu-mfd.c
@@ -0,0 +1,264 @@
+/*
+ * Retu MFD driver
+ *
+ * Copyright (C) 2004, 2005 Nokia Corporation
+ *
+ * Based on code written by Juha Yrjölä, David Weinehall and Mikko Ylinen.
+ * Rewritten by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/err.h
+#include linux/i2c.h
+#include linux/irq.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/mutex.h
+#include linux/module.h
+#include linux/regmap.h
+#include linux/mfd/core.h
+#include linux/mfd/retu.h
+#include linux/interrupt.h
+#include linux/moduleparam.h
+
+/* Registers */
+#define RETU_REG_ASICR 0x00/* ASIC ID and revision */
+#define RETU_REG_ASICR_VILMA (1 7)/* Bit indicating Vilma */
+#define RETU_REG_IDR 0x01/* Interrupt ID */
+#define RETU_REG_IMR 0x02/* Interrupt mask */
+
+/* Interrupt sources */
+#define RETU_INT_PWR 0 /* Power button */
+
+struct retu_dev {
+ struct regmap *regmap;
+ struct device *dev;
+ struct mutexmutex;
+ struct regmap_irq_chip_data *irq_data;
+};
+
+static struct resource retu_pwrbutton_res[] = {
+ {
+ .name = retu-pwrbutton,
+ .start = RETU_INT_PWR,
+ .end= RETU_INT_PWR,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct mfd_cell retu_devs[] = {
+ {
+ .name = retu-wdt
+ },
+ {
+ .name = retu-pwrbutton,
+ .resources = retu_pwrbutton_res,
+ .num_resources = ARRAY_SIZE(retu_pwrbutton_res),
+ }
+};
+
+static struct regmap_irq retu_irqs[] = {
+ [RETU_INT_PWR] = {
+ .mask = 1 RETU_INT_PWR,
+ }
+};
+
+static struct regmap_irq_chip retu_irq_chip = {
+ .name = RETU,
+ .irqs = retu_irqs,
+ .num_irqs = ARRAY_SIZE(retu_irqs),
+ .num_regs = 1,
+ .status_base= RETU_REG_IDR,
+ .mask_base = RETU_REG_IMR,
+ .ack_base = RETU_REG_IDR,
+};
+
+/* Retu device registered for the power off. */
+static struct retu_dev *retu_pm_power_off;
+
+int retu_read(struct retu_dev *rdev, u8 reg)
+{
+ int ret;
+ int value;
+
+ mutex_lock(rdev-mutex);
+ ret = regmap_read(rdev-regmap, reg, value);
+ mutex_unlock(rdev-mutex);
+
+ return ret ? ret : value;
+}
+EXPORT_SYMBOL_GPL(retu_read);
+
+int retu_write(struct retu_dev *rdev, u8 reg, u16 data)
+{
+ int ret;
+
+ mutex_lock(rdev-mutex);
+ ret = regmap_write(rdev-regmap, reg, data);
+
[PATCH v4 4/4] input: misc: introduce retu-pwrbutton
Add Retu power button driver.
Cc: linux-in...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/input/misc/Kconfig | 10
drivers/input/misc/Makefile |1 +
drivers/input/misc/retu-pwrbutton.c | 102 +++
3 files changed, 113 insertions(+)
create mode 100644 drivers/input/misc/retu-pwrbutton.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 7c0f1ec..e5be189 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -367,6 +367,16 @@ config INPUT_CM109
To compile this driver as a module, choose M here: the module will be
called cm109.
+config INPUT_RETU_PWRBUTTON
+ tristate Retu Power button Driver
+ depends on MFD_RETU
+ help
+ Say Y here if you want to enable power key reporting via the
+ Retu chips found in Nokia Internet Tablets (770, N800, N810).
+
+ To compile this driver as a module, choose M here. The module will
+ be called retu-pwrbutton.
+
config INPUT_TWL4030_PWRBUTTON
tristate TWL4030 Power button Driver
depends on TWL4030_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 83fe6f5..4fbee0d 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
+obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
obj-$(CONFIG_INPUT_SPARCSPKR) += sparcspkr.o
diff --git a/drivers/input/misc/retu-pwrbutton.c
b/drivers/input/misc/retu-pwrbutton.c
new file mode 100644
index 000..043a12b
--- /dev/null
+++ b/drivers/input/misc/retu-pwrbutton.c
@@ -0,0 +1,102 @@
+/*
+ * Retu power button driver.
+ *
+ * Copyright (C) 2004-2010 Nokia Corporation
+ *
+ * Original code written by Ari Saastamoinen, Juha Yrjölä and Felipe Balbi.
+ * Rewritten by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/irq.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/errno.h
+#include linux/input.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mfd/retu.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+
+#define RETU_STATUS_PWRONX (1 5)
+
+static irqreturn_t retu_pwrbutton_irq(int irq, void *_pwr)
+{
+ bool state;
+ struct input_dev *idev = _pwr;
+ struct retu_dev *rdev = input_get_drvdata(idev);
+
+ state = !(retu_read(rdev, RETU_REG_STATUS) RETU_STATUS_PWRONX);
+ input_report_key(idev, KEY_POWER, state);
+ input_sync(idev);
+
+ return IRQ_HANDLED;
+}
+
+static int __devinit retu_pwrbutton_probe(struct platform_device *pdev)
+{
+ struct retu_dev *rdev = dev_get_drvdata(pdev-dev.parent);
+ struct input_dev *idev;
+ int ret;
+
+ idev = input_allocate_device();
+ if (!idev)
+ return -ENOMEM;
+
+ idev-evbit[0] = BIT_MASK(EV_KEY);
+ idev-keybit[BIT_WORD(KEY_POWER)] = BIT_MASK(KEY_POWER);
+ idev-name = retu-pwrbutton;
+
+ platform_set_drvdata(pdev, idev);
+ input_set_drvdata(idev, rdev);
+
+ ret = input_register_device(idev);
+ if (ret 0) {
+ input_free_device(idev);
+ return ret;
+ }
+
+ ret = devm_request_threaded_irq(pdev-dev, platform_get_irq(pdev, 0),
+ NULL, retu_pwrbutton_irq, 0,
+ retu-pwrbutton, idev);
+ if (ret 0)
+ input_unregister_device(idev);
+
+ return ret;
+}
+
+static int __devexit retu_pwrbutton_remove(struct platform_device *pdev)
+{
+ struct input_dev *idev = platform_get_drvdata(pdev);
+
+ disable_irq(platform_get_irq(pdev, 0));
+ input_unregister_device(idev);
+
+ return 0;
+}
+
+static struct platform_driver retu_pwrbutton_driver = {
+ .probe = retu_pwrbutton_probe,
+ .remove = __devexit_p(retu_pwrbutton_remove),
+ .driver = {
+ .name = retu-pwrbutton,
+ .owner = THIS_MODULE,
+ },
+};
[PATCH v4 3/4] watchdog: introduce retu_wdt driver
Introduce Retu watchdog driver.
Cc: linux-watch...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: Wim Van Sebroeck w...@iguana.be
---
drivers/watchdog/Kconfig| 12 +++
drivers/watchdog/Makefile |1 +
drivers/watchdog/retu_wdt.c | 178 +++
3 files changed, 191 insertions(+)
create mode 100644 drivers/watchdog/retu_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ad1bb93..c3a836d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -352,6 +352,18 @@ config IMX2_WDT
To compile this driver as a module, choose M here: the
module will be called imx2_wdt.
+config RETU_WATCHDOG
+ tristate Retu watchdog
+ depends on MFD_RETU
+ select WATCHDOG_CORE
+ help
+ Retu watchdog driver for Nokia Internet Tablets (700, N800,
+ N810). At least on N800 the watchdog cannot be disabled, so
+ this driver is essential and you should enable it.
+
+ To compile this driver as a module, choose M here: the
+ module will be called retu_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 572b39b..d2f1c0c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_STMP3XXX_WATCHDOG) += stmp3xxx_wdt.o
obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
+obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/retu_wdt.c b/drivers/watchdog/retu_wdt.c
new file mode 100644
index 000..aeb0f39
--- /dev/null
+++ b/drivers/watchdog/retu_wdt.c
@@ -0,0 +1,178 @@
+/*
+ * Retu watchdog driver
+ *
+ * Copyright (C) 2004, 2005 Nokia Corporation
+ *
+ * Based on code written by Amit Kucheria and Michael Buesch.
+ * Rewritten by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/init.h
+#include linux/slab.h
+#include linux/errno.h
+#include linux/device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mfd/retu.h
+#include linux/watchdog.h
+#include linux/platform_device.h
+
+/* Watchdog timer values in seconds */
+#define RETU_WDT_MAX_TIMER 63
+
+struct retu_wdt_dev {
+ struct retu_dev *rdev;
+ struct device *dev;
+ struct delayed_work ping_work;
+};
+
+/*
+ * Since Retu watchdog cannot be disabled in hardware, we must kick it
+ * with a timer until userspace watchdog software takes over. If
+ * CONFIG_WATCHDOG_NOWAYOUT is set, we never start the feeding.
+ */
+static void retu_wdt_ping_enable(struct retu_wdt_dev *wdev)
+{
+ retu_write(wdev-rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
+ schedule_delayed_work(wdev-ping_work,
+ round_jiffies_relative(RETU_WDT_MAX_TIMER * HZ / 2));
+}
+
+static void retu_wdt_ping_disable(struct retu_wdt_dev *wdev)
+{
+ retu_write(wdev-rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
+ cancel_delayed_work_sync(wdev-ping_work);
+}
+
+static void retu_wdt_ping_work(struct work_struct *work)
+{
+ struct retu_wdt_dev *wdev = container_of(to_delayed_work(work),
+ struct retu_wdt_dev, ping_work);
+ retu_wdt_ping_enable(wdev);
+}
+
+static int retu_wdt_start(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ retu_wdt_ping_disable(wdev);
+
+ return retu_write(wdev-rdev, RETU_REG_WATCHDOG, wdog-timeout);
+}
+
+static int retu_wdt_stop(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ retu_wdt_ping_enable(wdev);
+
+ return 0;
+}
+
+static int retu_wdt_ping(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ return retu_write(wdev-rdev, RETU_REG_WATCHDOG, wdog-timeout);
+}
+
+static int retu_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int timeout)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ wdog-timeout = timeout;
+ return retu_write(wdev-rdev, RETU_REG_WATCHDOG, wdog-timeout);
+}
+
+static const struct watchdog_info retu_wdt_info = {
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
+ .identity = Retu watchdog,
+};
+
[PATCH v4 1/4] i2c: introduce i2c-cbus-gpio driver
Add i2c driver to enable access to devices behind CBUS on Nokia Internet
Tablets.
The patch also adds CBUS I2C configuration for N8x0 which is one of the
users of this driver.
Cc: linux-...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: Wolfram Sang w.s...@pengutronix.de
---
.../devicetree/bindings/i2c/i2c-cbus-gpio.txt | 27 ++
arch/arm/mach-omap2/board-n8x0.c | 42 +++
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile|1 +
drivers/i2c/busses/i2c-cbus-gpio.c | 300
include/linux/platform_data/i2c-cbus-gpio.h| 27 ++
6 files changed, 407 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
create mode 100644 drivers/i2c/busses/i2c-cbus-gpio.c
create mode 100644 include/linux/platform_data/i2c-cbus-gpio.h
diff --git a/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
new file mode 100644
index 000..8ce9cd2
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
@@ -0,0 +1,27 @@
+Device tree bindings for i2c-cbus-gpio driver
+
+Required properties:
+ - compatible = i2c-cbus-gpio;
+ - gpios: clk, dat, sel
+ - #address-cells = 1;
+ - #size-cells = 0;
+
+Optional properties:
+ - child nodes conforming to i2c bus binding
+
+Example:
+
+i2c@0 {
+ compatible = i2c-cbus-gpio;
+ gpios = gpio 66 0 /* clk */
+gpio 65 0 /* dat */
+gpio 64 0 /* sel */
+ ;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ retu-mfd: retu@1 {
+ compatible = retu-mfd;
+ reg = 0x1;
+ };
+};
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index d95f727..bbfd742 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -16,10 +16,12 @@
#include linux/gpio.h
#include linux/init.h
#include linux/io.h
+#include linux/irq.h
#include linux/stddef.h
#include linux/i2c.h
#include linux/spi/spi.h
#include linux/usb/musb.h
+#include linux/platform_data/i2c-cbus-gpio.h
#include linux/platform_data/spi-omap2-mcspi.h
#include linux/platform_data/mtd-onenand-omap2.h
#include sound/tlv320aic3x.h
@@ -39,6 +41,45 @@
#define TUSB6010_GPIO_ENABLE 0
#define TUSB6010_DMACHAN 0x3f
+#if defined(CONFIG_I2C_CBUS_GPIO) || defined(CONFIG_I2C_CBUS_GPIO_MODULE)
+static struct i2c_cbus_platform_data n8x0_cbus_data = {
+ .clk_gpio = 66,
+ .dat_gpio = 65,
+ .sel_gpio = 64,
+};
+
+static struct platform_device n8x0_cbus_device = {
+ .name = i2c-cbus-gpio,
+ .id = 3,
+ .dev= {
+ .platform_data = n8x0_cbus_data,
+ },
+};
+
+static struct i2c_board_info n8x0_i2c_board_info_3[] __initdata = {
+ {
+ I2C_BOARD_INFO(retu-mfd, 0x01),
+ },
+};
+
+static void __init n8x0_cbus_init(void)
+{
+ const int retu_irq_gpio = 108;
+
+ if (gpio_request_one(retu_irq_gpio, GPIOF_IN, Retu IRQ))
+ return;
+ irq_set_irq_type(gpio_to_irq(retu_irq_gpio), IRQ_TYPE_EDGE_RISING);
+ n8x0_i2c_board_info_3[0].irq = gpio_to_irq(retu_irq_gpio);
+ i2c_register_board_info(3, n8x0_i2c_board_info_3,
+ ARRAY_SIZE(n8x0_i2c_board_info_3));
+ platform_device_register(n8x0_cbus_device);
+}
+#else /* CONFIG_I2C_CBUS_GPIO */
+static void __init n8x0_cbus_init(void)
+{
+}
+#endif /* CONFIG_I2C_CBUS_GPIO */
+
#if defined(CONFIG_USB_MUSB_TUSB6010) ||
defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
/*
* Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
@@ -677,6 +718,7 @@ static void __init n8x0_init_machine(void)
gpmc_onenand_init(board_onenand_data);
n8x0_mmc_init();
n8x0_usb_init();
+ n8x0_cbus_init();
}
MACHINE_START(NOKIA_N800, Nokia N800)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index e9df461..e949edf 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -337,6 +337,16 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
help
The unit of the TWI clock is kHz.
+config I2C_CBUS_GPIO
+ tristate CBUS I2C driver
+ depends on GENERIC_GPIO
+ help
+ Support for CBUS access using I2C API. Mostly relevant for Nokia
+ Internet Tablets (770, N800 and N810).
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-cbus-gpio.
+
config I2C_CPM
tristate Freescale CPM1 or CPM2 (MPC8xx/826x)
depends on (CPM1 || CPM2) OF_I2C
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 395b516..f9e3e0b 100644
--- a/drivers/i2c/busses/Makefile
+++
Re: [PATCH] bq2415x charger driver
On Fri, Nov 02, 2012 at 08:18:11PM +0100, Pali Rohár wrote: Hello, I'm sending new version of bq2415x charger driver which is needed for example on Nokia N900 for charging battery. Driver is part of open source project to replace proprietary battery management. Driver is based on old RFC version which I sent months ago. power_supply: Add bq2415x charger driver This patch implements driver for bq2415x charging chips. Signed-off-by: Pali Rohár pali.ro...@gmail.com Applied, thanks! Note that I had to add the Makefile/Kconfig entries and fix some style issues... commit 7ad85830736f3e0d854becf7621eba3a0c926d13 Author: Anton Vorontsov cbouatmai...@gmail.com Date: Sun Nov 18 15:48:52 2012 -0800 bq2415x_charger: Add Kconfig/Makefile entries This commit adds Kconfig and Makefile entries so that we could actually build the driver. Signed-off-by: Anton Vorontsov cbouatmai...@gmail.com diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 5c3237f..523a580 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -322,6 +322,16 @@ config CHARGER_MAX8998 Say Y to enable support for the battery charger control sysfs and platform data of MAX8998/LP3974 PMICs. +config CHARGER_BQ2415X + tristate TI BQ2415x battery charger driver + depends on I2C + help + Say Y to enable support for the TI BQ2415x battery charger + PMICs. + + You'll need this driver to charge batteries on e.g. Nokia + RX-51/N900. + config CHARGER_SMB347 tristate Summit Microelectronics SMB347 Battery Charger depends on I2C diff --git a/drivers/power/Makefile b/drivers/power/Makefile index bc81fe2..74dfd95 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -48,5 +48,6 @@ obj-$(CONFIG_CHARGER_GPIO)+= gpio-charger.o obj-$(CONFIG_CHARGER_MANAGER) += charger-manager.o obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o +obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o obj-$(CONFIG_POWER_AVS)+= avs/ obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o -- 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] power: twl4030_charger: Change TWL4030_MODULE_* ids to TWL_MODULE_*
On Tue, Nov 13, 2012 at 10:42:11AM +0100, Peter Ujfalusi wrote: To facilitate upcoming cleanup in twl stack. No functional changes. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Applied, thanks! -- 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 4/4] ARM: dts: AM33XX: Enable system power off control in am335x-bone
On Sat, Nov 17, 2012 at 00:40:04, Kevin Hilman wrote:
AnilKumar Ch anilku...@ti.com writes:
Enable system power off control for BeagleBone in am335x-bone.dts file
under rtc node. RTC is the incharge of controlling the system power.
This flag is used by the driver to hook up the pm_power_off system call.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 1d55190..206c3eb 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -52,6 +52,10 @@
};
};
+
+ rtc@44e3e000 {
+ ti,system-power-controller;
+ };
};
Also, I think this series is missing a patch that allows the RTC driver
to be compiled on AM335x.
Hi Kevin,
Yes I missed; I will submit that as a separate patch.
Thanks
AnilKumar
--
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] OMAPDSS: OMAPFB: Fix possible null pointer dereferencing
If display is NULL, display-output would lead to kernel panic.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/video/omap2/omapfb/omapfb-ioctl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 55a39be..532a31b 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -787,7 +787,7 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd,
unsigned long arg)
case OMAPFB_WAITFORVSYNC:
DBG(ioctl WAITFORVSYNC\n);
- if (!display !display-output !display-output-manager) {
+ if (!display || !display-output || !display-output-manager) {
r = -EINVAL;
break;
}
--
1.7.4.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] ARM: OMAP3: Devkit8000: Fix dvi output
On 2012-11-18 18:28, Thomas Weber wrote:
Add i2c bus number for DVI output.
The driver uses this to detect if a panel is connected and to read EDID.
Signed-off-by: Thomas Weber tho...@tomweber.eu
Cc: sta...@vger.kernel.org #v3.5 v3.6
---
arch/arm/mach-omap2/board-devkit8000.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 1fd161e..73d3d8e 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -138,6 +138,7 @@ static struct omap_dss_device devkit8000_lcd_device = {
};
static struct tfp410_platform_data dvi_panel = {
+ .i2c_bus_num= 1,
.power_down_gpio= -1,
};
That change is already included in the [PATCH] OMAP: board-files: fix
i2c_bus for tfp410 path I sent on Friday.
Tomi
signature.asc
Description: OpenPGP digital signature
RE: [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Sun, Nov 11, 2012 at 00:26:32, Daniel Mack wrote:
On 07.11.2012 16:37, Philip, Avinash wrote:
On Wed, Nov 07, 2012 at 15:18:37, Daniel Mack wrote:
On 05.11.2012 14:29, Philip, Avinash wrote:
On Mon, Nov 05, 2012 at 18:28:22, Daniel Mack wrote:
On 05.11.2012 12:03, Philip, Avinash wrote:
On Fri, Nov 02, 2012 at 20:55:56, Daniel Mack wrote:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from child nodes within the
GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how to use them.
Successfully tested on an AM33xx board.
Signed-off-by: Daniel Mack zon...@gmail.com
[...]
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+ nand-bus-width = 16;
+ nand-ecc-mode = none;
+
+ gpmc,sync-clk = 0;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 36;
+ gpmc,cs-wr-off = 36;
+ gpmc,adv-on = 6;
+ gpmc,adv-rd-off = 24;
+ gpmc,adv-wr-off = 36;
+ gpmc,we-off = 30;
+ gpmc,oe-off = 48;
+ gpmc,access = 54;
+ gpmc,rd-cycle = 72;
+ gpmc,wr-cycle = 72;
+ gpmc,wr-access = 30;
+ gpmc,wr-data-mux-bus = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+
Can you take the timings (for example) from arago tree. The timings is
tested in am335x-evm
So the timings can be directly used to populate GPMC timings. Timings
can found at
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;
h=66bfbd2c5b35dc81edce0c24843c476161ab5978;hp=370630359cb8db711cf0941cd2a242e28ccfb61e
[...]
+static int gpmc_probe_dt(struct platform_device *pdev)
Can you take care of the following section mismatch.
WARNING: vmlinux.o(.text+0x1e2d0): Section mismatch in reference
from the function gpmc_probe_dt() to the function
.init.text:gpmc_nand_init().
Sore, both fixed for v4.
[...]
+
+ val = of_get_nand_ecc_mode(child);
+ if (val = 0)
+ gpmc_nand_data-ecc_opt = val;
This will fail for BCH. Index of soft_bch is 5 also don't have
selection
option between for BCH4 BCH8 also.
Can you use the of_property_read_u32 (as done early) to pass the ecc
selection
from dt file. This will help selection of BCH4 BCH8 ecc options.
Hmm. Shouldn't we rather teach of_get_nand_ecc_mode() that two modes and
bring the enum in sync?
ecc_opt is for selecting different ecc layout and not for selecting ecc
mode.
In omap2 driver NAND_ECC_HW ecc mode supports 3 ecc layout
OMAP_ECC_HAMMING_CODE_HW_ROMCODE
OMAP_ECC_BCH4_CODE_HW
OMAP_ECC_BCH8_CODE_HW
So selection of ecc layout data should come from DT not ecc mode.
Ok, I see. I would still like to set them by string rather than magic
numbers that map to enum entries. Valid values would be none, hw,
hw-romcode, bch4 and bch8. Are you ok with that?
Ok, that's nice. Better use ecc_opt instead of ecc_mode.
I did some more extensive tests that include reading the same nand pages
from both U-Boot and the kernel with BCH8 ECC, and it turns out that
-is_elm_used needs to be set in the pdata in order to make this work.
So the question is whether we actually want to have a DT property for
that or just always enable that bit in case a hardware supported ecc
mode is selected. Any opinion on this?
Yes, is_elm_used data should come from DT. There may be hardware which uses
BCH8 ecc scheme even without ELM hardware support with software error correction
support. So is_elm_used data should come from DT property.
Thanks
Avinash
That's the last topic before I'm clear to send off v4.
Thanks,
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] ARM: OMAP3: Devkit8000: Fix dvi output
Hello Tomi,
On 11/19/2012 06:52 AM, Tomi Valkeinen wrote:
On 2012-11-18 18:28, Thomas Weber wrote:
Add i2c bus number for DVI output.
The driver uses this to detect if a panel is connected and to read EDID.
Signed-off-by: Thomas Weber tho...@tomweber.eu
Cc: sta...@vger.kernel.org #v3.5 v3.6
---
arch/arm/mach-omap2/board-devkit8000.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 1fd161e..73d3d8e 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -138,6 +138,7 @@ static struct omap_dss_device devkit8000_lcd_device = {
};
static struct tfp410_platform_data dvi_panel = {
+ .i2c_bus_num= 1,
.power_down_gpio= -1,
};
That change is already included in the [PATCH] OMAP: board-files: fix
i2c_bus for tfp410 path I sent on Friday.
Tomi
Thanks.
Thomas
--
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: tfp410 and i2c_bus_num
(dropping Tony and stable) On 2012-11-18 13:34, Felipe Balbi wrote: how are you toggling the gpio ? You said tfp410 isn't controlled at all except for the power down gpio. Who provides the gpio ? It's a normal OMAP GPIO, going to TFP410. I use gpio_set_value() to set/unset it. Well, it's not that simple. TFP410 manages hot plug detection of the HDMI cable (although not implemented currently), so the we'd need to convey that information to the i2c-edid somehow. Which, of course, is doable, but increases complexity. I'd say it would decrease it since you would have a single copy of i2c-edid.c for DRM or DSS or any other panel/display framework. Well. Reading EDID via i2c is one or two i2c reads. There's nothing else to it. If we had a separate, independent i2c-edid driver, we'd have to somehow link the i2c-edid driver and tfp410 (or whatever driver would handle the video link in that particular case) so that the i2c-edid driver would know about hotplug events. We would also need to link the drivers so that the edid can be associated with the video pipeline the tfp410 chip is part of, and to the particular slot in the pipeline where the tfp410 is. I haven't tried writing such a driver, but it sounds much more complex to me than doing one or two i2c reads in the tfp410 driver. Another thing is that even if in this case the i2c and EDID reading are separate from the actual video path, that may not be the case for other display solutions. We could have a DSI panel which reports its resolution via DSI bus, or we could have an external DSI-to-HDMI chip, which reads the EDID via i2c from the monitor, but reports them back to the SoC via DSI bus. In this last case we would see just the DSI, not the I2C bus, so it's like I2C bus doesn't exist, so in fact we would have two possibilities: a) read EDID via I2C bus (standard HDMI) b) read EDID via DSI. Right. And currently reading edid is done via read_edid call with omapdss, and the caller doesn't care if read_edid uses i2c or DSI, so it should just work. b) doesn't exist today so we need to care about it until something like what you say shows up in the market. Until then, we care for EDID over I2C IMHO. There are chips such as I described, although not supported in the mainline. So we need a generic way to get the resolution information, and it makes sense to have this in the components of the video path, not in a separate driver which is not part of the video path as such. But the I2C bus isn't part of the video path anyway. It's a completely separate path which is dedicated to reading EDID. If you need a generic While reading EDID is totally separate from the video data itself, it is not separate from the hotplug status of the cable. And the EDID needs to be associated with the video path in question, of course. way for that case you wanna cope with other methods for reading EDID, then you need a generic layer which doesn't care if it's I2C or DSI. Currently implementation is hardcoded to I2C anyway. No, reading edid is done via generic read_edid call. TFP410 uses i2c to read edid, but it could do it in any way it wants. In fact current implementation is far worse than having an extra i2c-edid.c driver because it doesn't encapsulate EDID implementation from tfp410. Then moment you need to read EDID via DSI, you will likely have to pass a DSI handle to e.g. TFP410 so it can read EDID via DSI. TFP410 is a parallel RGB to DVI chip. It's not related to DSI. The DSI case would be with some other chip. What I'm suggesting, however, is that you have a layer hiding all that. Make your i2c-edid.c driver read EDID and report it to this generic layer, if some other driver in kernel needs the information, you should be calling into this generic edid layer to get the cached values. If you don't need that data in kernel, then just expose it through a set of standard sysfs files and teach Xorg about those. We need the data in the kernel. And while the above issues could perhaps be solved, all we do is read one or two 128 byte datablocks from the i2c device. I'm not sure if the extra complexity is worth it. At least it's not on the top of my todo When you have EDID over DSI, what will you do ? Write the code to read the EDID =). How that is done in practice depends on the chip in question, using chip specific DSI commands. list as long as the current solution works =). that's your choice. If you have a generic i2c-edid.c simple driver, I guess X could be changes to read those values from sysfs and take actions based on those. We handle the EDID inside the kernel, although I'm not sure if drm also exposes the EDID to userspace. I suppose it does, but haven't looked through the code. Looks like even drm_edid.c should change, btw. Yes, DRM handles it in somewhat similar way. another reason to make a generic i2c-edid.c. It make no sense to have two pieces of code doing exactly the
[PATCH] spi: omap2-mcspi: Fix the redifine warning
Fix the below warning
drivers/spi/spi-omap2-mcspi.c:336:34: warning: symbol 'tx' shadows an earlier
one
drivers/spi/spi-omap2-mcspi.c:327:12: originally declared here
So delete the u8 tx as it is assigned and not used(resigned afterwards).
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 251f6d0..c3dcfb3 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -323,14 +323,11 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
struct omap2_mcspi *mcspi;
struct omap2_mcspi_dma *mcspi_dma;
unsigned intcount;
- const u8* tx;
mcspi = spi_master_get_devdata(spi-master);
mcspi_dma = mcspi-dma_channels[spi-chip_select];
count = xfer-len;
- tx = xfer-tx_buf;
-
if (mcspi_dma-dma_tx) {
struct dma_async_tx_descriptor *tx;
struct scatterlist sg;
--
1.7.5.4
--
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
