* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Tomi Valkeinen @ 2012-05-10 6:54 UTC (permalink / raw)
To: Russ Dill; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336601288-27848-1-git-send-email-Russ.Dill@ti.com>
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
On Wed, 2012-05-09 at 15:08 -0700, Russ Dill wrote:
> The Beagleboard xM gpio used for TFP410 powerdown is connected through
> an I2C attached chip which means setting the GPIO can sleep. Code that
> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
>
> Signed-off-by: Russ Dill <Russ.Dill@ti.com>
> ---
> drivers/video/omap2/displays/panel-tfp410.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
I'll apply this to dss tree, thanks.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Tomi Valkeinen @ 2012-05-10 6:53 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Russ Dill, linux-omap, linux-fbdev
In-Reply-To: <20120509233745.GZ5088@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]
On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote:
> * Russ Dill <Russ.Dill@ti.com> [120509 15:53]:
> > On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > * Russ Dill <Russ.Dill@ti.com> [120509 15:12]:
> > >> The Beagleboard xM gpio used for TFP410 powerdown is connected through
> > >> an I2C attached chip which means setting the GPIO can sleep. Code that
> > >> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
> > >
> > > What's the error without this patch? Or just no display?
> > >
> > > Just wondering if it's safe to merge Tomi's clean up series to
> > > arm-soc tree..
> >
> > The only platform that has a problem is Beagleboard xM, and that is
> > only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied.
> > Since the context actually can sleep, the only consequence is a
> > WARN_ON statement.
> >
> > So yes, it should be safe.
>
> Well since I have not actually merged it with other branches yet, I'll wait
> for Tomi to apply that and repull his for-l-o-3.5 branch.
You can pull for-l-o-3.5 as it is now, there's no need to change it.
This _cansleep change is a separate dss specific change.
So to summarize:
Currently the powerdown GPIO for tfp410 is handled in the board files
(and called reset gpio), with gpio_set_value(). My cleanup series moves
this to the tfp410 driver.
BB-xM needs to use gpio_set_value_cansleep() in tfp410 to function
properly, so the tfp410 driver needs to be changed, as this patch does.
I will take this patch to the dss tree.
So it's safe to pull my cleanup series, but if I understood correctly,
applying Russ's "[PATCH v4] ARM: OMAP: Cleanup Beagleboard DVI reset
gpio" will cause WARN_ONs on BB-xM until this patch to tfp410 is also
applied.
But it doesn't sound too serious, so I think it's safe to apply the
"cleanup beagleboard dvi" patch also. The warning will go away when both
l-o and dss trees are pulled in the merge window.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] video: EXYNOS: enable interrupt again after sw reset
From: Florian Tobias Schandinat @ 2012-05-10 0:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4FA3622A.7060401@samsung.com>
On 05/04/2012 04:59 AM, Donghwa Lee wrote:
> When exynos_mipi_update_cfg() is called, mipi dsi registers were become
> sw reset. So, It needs to enable interrupt again.
>
> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
> Signed-off-by: Inki Dae <inki.dae@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/exynos/exynos_mipi_dsi.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
> index 557091d..49c7351 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -102,6 +102,8 @@ static void exynos_mipi_update_cfg(struct mipi_dsim_device *dsim)
> /* set display timing. */
> exynos_mipi_dsi_set_display_mode(dsim, dsim->dsim_config);
>
> + exynos_mipi_dsi_init_interrupt(dsim);
> +
> /*
> * data from Display controller(FIMD) is transferred in video mode
> * but in case of command mode, all settigs is updated to registers.
^ permalink raw reply
* Re: [PATCH] video: exynos_dp: fix max loop count in EQ sequence of link training
From: Florian Tobias Schandinat @ 2012-05-10 0:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <003201cd2998$2ee3eef0$8cabccd0$%han@samsung.com>
On 05/04/2012 01:49 AM, Jingoo Han wrote:
> This patch fixes max loop count in EQ(Channel Equalization) sequence
> of link training. According to DP(displayport) specification,
> the max loop count in this sequence should be 5.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> include/video/exynos_dp.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/video/exynos_dp.h b/include/video/exynos_dp.h
> index 8847a9d..bd8cabd 100644
> --- a/include/video/exynos_dp.h
> +++ b/include/video/exynos_dp.h
> @@ -14,7 +14,7 @@
>
> #define DP_TIMEOUT_LOOP_COUNT 100
> #define MAX_CR_LOOP 5
> -#define MAX_EQ_LOOP 4
> +#define MAX_EQ_LOOP 5
>
> enum link_rate_type {
> LINK_RATE_1_62GBPS = 0x06,
^ permalink raw reply
* Re: [PATCH v2] video/via: Convert to kstrtou8_from_user
From: Florian Tobias Schandinat @ 2012-05-10 0:19 UTC (permalink / raw)
To: Peter Huewe; +Cc: Alexey Dobriyan, linux-fbdev, linux-kernel, kernel-janitors
In-Reply-To: <1336090997-23727-1-git-send-email-peterhuewe@gmx.de>
On 05/04/2012 12:23 AM, Peter Huewe wrote:
> This patch replaces the code for getting an number from a
> userspace buffer by a simple call to kstrou8_from_user.
> This makes it easier to read and less error prone.
>
> v2:
> removed initialization of reg_val and dropped check if count < 1
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> @Alexey: Thanks for the review/feedback!
> drivers/video/via/viafbdev.c | 34 ++++++++++++----------------------
> 1 files changed, 12 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
> index a13c258..88bf5ba 100644
> --- a/drivers/video/via/viafbdev.c
> +++ b/drivers/video/via/viafbdev.c
> @@ -1279,17 +1279,12 @@ static int viafb_dfph_proc_open(struct inode *inode, struct file *file)
> static ssize_t viafb_dfph_proc_write(struct file *file,
> const char __user *buffer, size_t count, loff_t *pos)
> {
> - char buf[20];
> - u8 reg_val = 0;
> - unsigned long length;
> - if (count < 1)
> - return -EINVAL;
> - length = count > 20 ? 20 : count;
> - if (copy_from_user(&buf[0], buffer, length))
> - return -EFAULT;
> - buf[length - 1] = '\0'; /*Ensure end string */
> - if (kstrtou8(buf, 0, ®_val) < 0)
> - return -EINVAL;
> + int err;
> + u8 reg_val;
> + err = kstrtou8_from_user(buffer, count, 0, ®_val);
> + if (err)
> + return err;
> +
> viafb_write_reg_mask(CR97, VIACR, reg_val, 0x0f);
> return count;
> }
> @@ -1319,17 +1314,12 @@ static int viafb_dfpl_proc_open(struct inode *inode, struct file *file)
> static ssize_t viafb_dfpl_proc_write(struct file *file,
> const char __user *buffer, size_t count, loff_t *pos)
> {
> - char buf[20];
> - u8 reg_val = 0;
> - unsigned long length;
> - if (count < 1)
> - return -EINVAL;
> - length = count > 20 ? 20 : count;
> - if (copy_from_user(&buf[0], buffer, length))
> - return -EFAULT;
> - buf[length - 1] = '\0'; /*Ensure end string */
> - if (kstrtou8(buf, 0, ®_val) < 0)
> - return -EINVAL;
> + int err;
> + u8 reg_val;
> + err = kstrtou8_from_user(buffer, count, 0, ®_val);
> + if (err)
> + return err;
> +
> viafb_write_reg_mask(CR99, VIACR, reg_val, 0x0f);
> return count;
> }
^ permalink raw reply
* Re: [PATCH] video/sis: Annotate SiS_DRAMType as __devinitconst
From: Florian Tobias Schandinat @ 2012-05-10 0:19 UTC (permalink / raw)
To: Peter Huewe; +Cc: Thomas Winischhofer, linux-fbdev, linux-kernel
In-Reply-To: <1336083295-7327-1-git-send-email-peterhuewe@gmx.de>
On 05/03/2012 10:14 PM, Peter Huewe wrote:
> SiS_DRAMType is const and only used by sisfb_post_300_rwtest which is
> marked __devinit we can annotate SiS_DRAMType with __devinitconst and
> move it into the file scope in order to not have it created on the
> stack.
> This patch decreases the compiled module size by about 100bytes.
>
> And since hardcoded values are bad we use ARRAY_SIZE for determining
> the size of SiS_DRAMType ;)
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Good that you did this one, it was more to be done than I expected. I
ignored the checkpatch errors as you didn't introduce them but maybe it
wouldn't be a bad idea to fix things up if you touch them. Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/sis/sis_main.c | 41 +++++++++++++++++++++--------------------
> 1 files changed, 21 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/video/sis/sis_main.c b/drivers/video/sis/sis_main.c
> index 078ca21..a7a48db 100644
> --- a/drivers/video/sis/sis_main.c
> +++ b/drivers/video/sis/sis_main.c
> @@ -4222,6 +4222,26 @@ sisfb_post_300_buswidth(struct sis_video_info *ivideo)
> return 1; /* 32bit */
> }
>
> +static const unsigned short __devinitconst SiS_DRAMType[17][5] = {
> + {0x0C,0x0A,0x02,0x40,0x39},
> + {0x0D,0x0A,0x01,0x40,0x48},
> + {0x0C,0x09,0x02,0x20,0x35},
> + {0x0D,0x09,0x01,0x20,0x44},
> + {0x0C,0x08,0x02,0x10,0x31},
> + {0x0D,0x08,0x01,0x10,0x40},
> + {0x0C,0x0A,0x01,0x20,0x34},
> + {0x0C,0x09,0x01,0x08,0x32},
> + {0x0B,0x08,0x02,0x08,0x21},
> + {0x0C,0x08,0x01,0x08,0x30},
> + {0x0A,0x08,0x02,0x04,0x11},
> + {0x0B,0x0A,0x01,0x10,0x28},
> + {0x09,0x08,0x02,0x02,0x01},
> + {0x0B,0x09,0x01,0x08,0x24},
> + {0x0B,0x08,0x01,0x04,0x20},
> + {0x0A,0x08,0x01,0x02,0x10},
> + {0x09,0x08,0x01,0x01,0x00}
> +};
> +
> static int __devinit
> sisfb_post_300_rwtest(struct sis_video_info *ivideo, int iteration, int buswidth,
> int PseudoRankCapacity, int PseudoAdrPinCount,
> @@ -4231,27 +4251,8 @@ sisfb_post_300_rwtest(struct sis_video_info *ivideo, int iteration, int buswidth
> unsigned short sr14;
> unsigned int k, RankCapacity, PageCapacity, BankNumHigh, BankNumMid;
> unsigned int PhysicalAdrOtherPage, PhysicalAdrHigh, PhysicalAdrHalfPage;
> - static const unsigned short SiS_DRAMType[17][5] = {
> - {0x0C,0x0A,0x02,0x40,0x39},
> - {0x0D,0x0A,0x01,0x40,0x48},
> - {0x0C,0x09,0x02,0x20,0x35},
> - {0x0D,0x09,0x01,0x20,0x44},
> - {0x0C,0x08,0x02,0x10,0x31},
> - {0x0D,0x08,0x01,0x10,0x40},
> - {0x0C,0x0A,0x01,0x20,0x34},
> - {0x0C,0x09,0x01,0x08,0x32},
> - {0x0B,0x08,0x02,0x08,0x21},
> - {0x0C,0x08,0x01,0x08,0x30},
> - {0x0A,0x08,0x02,0x04,0x11},
> - {0x0B,0x0A,0x01,0x10,0x28},
> - {0x09,0x08,0x02,0x02,0x01},
> - {0x0B,0x09,0x01,0x08,0x24},
> - {0x0B,0x08,0x01,0x04,0x20},
> - {0x0A,0x08,0x01,0x02,0x10},
> - {0x09,0x08,0x01,0x01,0x00}
> - };
>
> - for(k = 0; k <= 16; k++) {
> + for(k = 0; k < ARRAY_SIZE(SiS_DRAMType); k++) {
>
> RankCapacity = buswidth * SiS_DRAMType[k][3];
>
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: s3c_fb_missing_pixclock() can't be __devinit
From: Mark Brown @ 2012-05-10 0:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1334486344-24073-1-git-send-email-broonie@opensource.wolfsonmicro.com>
[-- Attachment #1: Type: text/plain, Size: 706 bytes --]
On Thu, May 10, 2012 at 12:10:13AM +0000, Florian Tobias Schandinat wrote:
> On 04/15/2012 10:39 AM, Mark Brown wrote:
> > Since s3c_fb_missing_pixclock() is called from s3c_fb_set_rgb_timing()
> > which is used in the suspend/resume paths it can't be marked __devinit
> > as this could result in it being discarded after boot.
> > Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> I'm not sure that this can actually happen. But the code looks saner
> with the patch applied so I applied it.
Thanks. To trigger you'd need to disable CONFIG_HOTPLUG and modules
(possibly some other stuff too) but the main motiviation is that the
build system complains loudly about section mismatches.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] video/sis: Remove unused structs SiS_SDRDRAM_TYPE/SiS_DDRDRAM_TYPE/SiS_DRAMType
From: Florian Tobias Schandinat @ 2012-05-10 0:13 UTC (permalink / raw)
To: Peter Huewe; +Cc: Thomas Winischhofer, linux-fbdev, linux-kernel
In-Reply-To: <1336081359-5643-1-git-send-email-peterhuewe@gmx.de>
On 05/03/2012 09:42 PM, Peter Huewe wrote:
> This patch removes the unused structs SiS_SDRDRAM_TYPE and SiS_DDRDRAM_TYPE
> from init.h
>
> These are not used anywhere so we can delete them.
>
> The SiS_DRAMType is identically defined in sis_main.c and only used
> there so we can remove it here.
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/sis/init.h | 45 ---------------------------------------------
> 1 files changed, 0 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/video/sis/init.h b/drivers/video/sis/init.h
> index aff7384..85d6738 100644
> --- a/drivers/video/sis/init.h
> +++ b/drivers/video/sis/init.h
> @@ -105,51 +105,6 @@ static const unsigned short ModeIndex_1920x1440[] = {0x68, 0x69, 0x00, 0x6b};
> static const unsigned short ModeIndex_300_2048x1536[]= {0x6c, 0x6d, 0x00, 0x00};
> static const unsigned short ModeIndex_310_2048x1536[]= {0x6c, 0x6d, 0x00, 0x6e};
>
> -static const unsigned short SiS_DRAMType[17][5]={
> - {0x0C,0x0A,0x02,0x40,0x39},
> - {0x0D,0x0A,0x01,0x40,0x48},
> - {0x0C,0x09,0x02,0x20,0x35},
> - {0x0D,0x09,0x01,0x20,0x44},
> - {0x0C,0x08,0x02,0x10,0x31},
> - {0x0D,0x08,0x01,0x10,0x40},
> - {0x0C,0x0A,0x01,0x20,0x34},
> - {0x0C,0x09,0x01,0x08,0x32},
> - {0x0B,0x08,0x02,0x08,0x21},
> - {0x0C,0x08,0x01,0x08,0x30},
> - {0x0A,0x08,0x02,0x04,0x11},
> - {0x0B,0x0A,0x01,0x10,0x28},
> - {0x09,0x08,0x02,0x02,0x01},
> - {0x0B,0x09,0x01,0x08,0x24},
> - {0x0B,0x08,0x01,0x04,0x20},
> - {0x0A,0x08,0x01,0x02,0x10},
> - {0x09,0x08,0x01,0x01,0x00}
> -};
> -
> -static const unsigned short SiS_SDRDRAM_TYPE[13][5] > -{
> - { 2,12, 9,64,0x35},
> - { 1,13, 9,64,0x44},
> - { 2,12, 8,32,0x31},
> - { 2,11, 9,32,0x25},
> - { 1,12, 9,32,0x34},
> - { 1,13, 8,32,0x40},
> - { 2,11, 8,16,0x21},
> - { 1,12, 8,16,0x30},
> - { 1,11, 9,16,0x24},
> - { 1,11, 8, 8,0x20},
> - { 2, 9, 8, 4,0x01},
> - { 1,10, 8, 4,0x10},
> - { 1, 9, 8, 2,0x00}
> -};
> -
> -static const unsigned short SiS_DDRDRAM_TYPE[4][5] > -{
> - { 2,12, 9,64,0x35},
> - { 2,12, 8,32,0x31},
> - { 2,11, 8,16,0x21},
> - { 2, 9, 8, 4,0x01}
> -};
> -
> static const unsigned char SiS_MDA_DAC[] > {
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
^ permalink raw reply
* Re: [PATCH] video: mb862xxfbdrv.c: local functions should not be exposed globally
From: Florian Tobias Schandinat @ 2012-05-10 0:12 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: Linux Kernel, linux-fbdev, agust
In-Reply-To: <201205021737.35719.hartleys@visionengravers.com>
On 05/03/2012 12:37 AM, H Hartley Sweeten wrote:
> Functions not referenced outside of a source file should be marked
> static to prevent them from being exposed globally.
>
> Quiets the sparse warnings:
>
> warning: symbol 'mb862xx_intr' was not declared. Should it be static?
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: Anatolij Gustschin <agust@denx.de>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
>
> diff --git a/drivers/video/mb862xx/mb862xxfbdrv.c b/drivers/video/mb862xx/mb862xxfbdrv.c
> index 11a7a33..00ce1f3 100644
> --- a/drivers/video/mb862xx/mb862xxfbdrv.c
> +++ b/drivers/video/mb862xx/mb862xxfbdrv.c
> @@ -579,7 +579,7 @@ static ssize_t mb862xxfb_show_dispregs(struct device *dev,
>
> static DEVICE_ATTR(dispregs, 0444, mb862xxfb_show_dispregs, NULL);
>
> -irqreturn_t mb862xx_intr(int irq, void *dev_id)
> +static irqreturn_t mb862xx_intr(int irq, void *dev_id)
> {
> struct mb862xxfb_par *par = (struct mb862xxfb_par *) dev_id;
> unsigned long reg_ist, mask;
>
^ permalink raw reply
* Re: [PATCH] video: mb862xx-i2c: local functions should not be exposed globally
From: Florian Tobias Schandinat @ 2012-05-10 0:12 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: Linux Kernel, linux-fbdev, agust
In-Reply-To: <201205021734.16988.hartleys@visionengravers.com>
On 05/03/2012 12:34 AM, H Hartley Sweeten wrote:
> Functions not referenced outside of a source file should be marked
> static to prevent them from being exposed globally.
>
> Quiets the sparse warnings:
>
> warning: symbol 'mb862xx_i2c_stop' was not declared. Should it be static?
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: Anatolij Gustschin <agust@denx.de>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
>
> diff --git a/drivers/video/mb862xx/mb862xx-i2c.c b/drivers/video/mb862xx/mb862xx-i2c.c
> index 273769b..c87e17a 100644
> --- a/drivers/video/mb862xx/mb862xx-i2c.c
> +++ b/drivers/video/mb862xx/mb862xx-i2c.c
> @@ -68,7 +68,7 @@ static int mb862xx_i2c_read_byte(struct i2c_adapter *adap, u8 *byte, int last)
> return 1;
> }
>
> -void mb862xx_i2c_stop(struct i2c_adapter *adap)
> +static void mb862xx_i2c_stop(struct i2c_adapter *adap)
> {
> struct mb862xxfb_par *par = adap->algo_data;
>
>
^ permalink raw reply
* Re: [PATCH] video: fb_defio.c: local functions should not be exposed globally
From: Florian Tobias Schandinat @ 2012-05-10 0:11 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: Linux Kernel, linux-fbdev
In-Reply-To: <201205021723.40801.hartleys@visionengravers.com>
On 05/03/2012 12:23 AM, H Hartley Sweeten wrote:
> Functions not referenced outside of a source file should be marked
> static to prevent them from being exposed globally.
>
> Quiets the sparse warning:
>
> warning: symbol 'fb_deferred_io_page' was not declared. Should it be static?
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Jaya Kumar <jayalk@intworks.biz>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
>
> diff --git a/drivers/video/fb_defio.c b/drivers/video/fb_defio.c
> index 070f26f..1ddeb11 100644
> --- a/drivers/video/fb_defio.c
> +++ b/drivers/video/fb_defio.c
> @@ -23,7 +23,7 @@
> #include <linux/rmap.h>
> #include <linux/pagemap.h>
>
> -struct page *fb_deferred_io_page(struct fb_info *info, unsigned long offs)
> +static struct page *fb_deferred_io_page(struct fb_info *info, unsigned long offs)
> {
> void *screen_base = (void __force *) info->screen_base;
> struct page *page;
>
^ permalink raw reply
* Re: [PATCH] video: smscufx.c: local functions should not be exposed globally
From: Florian Tobias Schandinat @ 2012-05-10 0:11 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: Linux Kernel, linux-fbdev, steve.glendinning
In-Reply-To: <201205021717.23749.hartleys@visionengravers.com>
On 05/03/2012 12:17 AM, H Hartley Sweeten wrote:
> Functions not referenced outside of a source file should be marked
> static to prevent them from being exposed globally.
>
> Quiets the sparse warnings:
>
> warning: symbol 'ufx_handle_damage' was not declared. Should it be static?
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Steve Glendinning <steve.glendinning@smsc.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
>
> diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c
> index 9985785..af3ef27 100644
> --- a/drivers/video/smscufx.c
> +++ b/drivers/video/smscufx.c
> @@ -846,7 +846,7 @@ static void ufx_raw_rect(struct ufx_data *dev, u16 *cmd, int x, int y,
> }
> }
>
> -int ufx_handle_damage(struct ufx_data *dev, int x, int y,
> +static int ufx_handle_damage(struct ufx_data *dev, int x, int y,
> int width, int height)
> {
> size_t packed_line_len = ALIGN((width * 2), 4);
>
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: s3c_fb_missing_pixclock() can't be __devinit
From: Florian Tobias Schandinat @ 2012-05-10 0:10 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1334486344-24073-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On 04/15/2012 10:39 AM, Mark Brown wrote:
> Since s3c_fb_missing_pixclock() is called from s3c_fb_set_rgb_timing()
> which is used in the suspend/resume paths it can't be marked __devinit
> as this could result in it being discarded after boot.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
I'm not sure that this can actually happen. But the code looks saner
with the patch applied so I applied it.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/s3c-fb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 18c84b8..d8f0018 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1056,7 +1056,7 @@ static struct fb_ops s3c_fb_ops = {
> *
> * Calculate the pixel clock when none has been given through platform data.
> */
> -static void __devinit s3c_fb_missing_pixclock(struct fb_videomode *mode)
> +static void s3c_fb_missing_pixclock(struct fb_videomode *mode)
> {
> u64 pixclk = 1000000000000ULL;
> u32 div;
^ permalink raw reply
* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Tony Lindgren @ 2012-05-09 23:37 UTC (permalink / raw)
To: Russ Dill; +Cc: linux-omap, linux-fbdev, Tomi Valkeinen
In-Reply-To: <CA+Bv8Xa+1RJ5QTn=vO4GSw1VtUZc3xX0J5qBVshvV5Dj+9uZVA@mail.gmail.com>
* Russ Dill <Russ.Dill@ti.com> [120509 15:53]:
> On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Russ Dill <Russ.Dill@ti.com> [120509 15:12]:
> >> The Beagleboard xM gpio used for TFP410 powerdown is connected through
> >> an I2C attached chip which means setting the GPIO can sleep. Code that
> >> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
> >
> > What's the error without this patch? Or just no display?
> >
> > Just wondering if it's safe to merge Tomi's clean up series to
> > arm-soc tree..
>
> The only platform that has a problem is Beagleboard xM, and that is
> only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied.
> Since the context actually can sleep, the only consequence is a
> WARN_ON statement.
>
> So yes, it should be safe.
Well since I have not actually merged it with other branches yet, I'll wait
for Tomi to apply that and repull his for-l-o-3.5 branch.
Tony
^ permalink raw reply
* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Russ Dill @ 2012-05-09 22:50 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev
In-Reply-To: <20120509221447.GY5088@atomide.com>
On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Russ Dill <Russ.Dill@ti.com> [120509 15:12]:
>> The Beagleboard xM gpio used for TFP410 powerdown is connected through
>> an I2C attached chip which means setting the GPIO can sleep. Code that
>> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
>
> What's the error without this patch? Or just no display?
>
> Just wondering if it's safe to merge Tomi's clean up series to
> arm-soc tree..
The only platform that has a problem is Beagleboard xM, and that is
only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied.
Since the context actually can sleep, the only consequence is a
WARN_ON statement.
So yes, it should be safe.
>> Signed-off-by: Russ Dill <Russ.Dill@ti.com>
>> ---
>> drivers/video/omap2/displays/panel-tfp410.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
>> index 52637fa..1266520 100644
>> --- a/drivers/video/omap2/displays/panel-tfp410.c
>> +++ b/drivers/video/omap2/displays/panel-tfp410.c
>> @@ -68,7 +68,7 @@ static int tfp410_power_on(struct omap_dss_device *dssdev)
>> goto err0;
>>
>> if (gpio_is_valid(ddata->pd_gpio))
>> - gpio_set_value(ddata->pd_gpio, 1);
>> + gpio_set_value_cansleep(ddata->pd_gpio, 1);
>>
>> return 0;
>> err0:
>> @@ -83,7 +83,7 @@ static void tfp410_power_off(struct omap_dss_device *dssdev)
>> return;
>>
>> if (gpio_is_valid(ddata->pd_gpio))
>> - gpio_set_value(ddata->pd_gpio, 0);
>> + gpio_set_value_cansleep(ddata->pd_gpio, 0);
>>
>> omapdss_dpi_display_disable(dssdev);
>> }
>> --
>> 1.7.10
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Tony Lindgren @ 2012-05-09 22:14 UTC (permalink / raw)
To: Russ Dill; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336601288-27848-1-git-send-email-Russ.Dill@ti.com>
* Russ Dill <Russ.Dill@ti.com> [120509 15:12]:
> The Beagleboard xM gpio used for TFP410 powerdown is connected through
> an I2C attached chip which means setting the GPIO can sleep. Code that
> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
What's the error without this patch? Or just no display?
Just wondering if it's safe to merge Tomi's clean up series to
arm-soc tree..
Tony
> Signed-off-by: Russ Dill <Russ.Dill@ti.com>
> ---
> drivers/video/omap2/displays/panel-tfp410.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
> index 52637fa..1266520 100644
> --- a/drivers/video/omap2/displays/panel-tfp410.c
> +++ b/drivers/video/omap2/displays/panel-tfp410.c
> @@ -68,7 +68,7 @@ static int tfp410_power_on(struct omap_dss_device *dssdev)
> goto err0;
>
> if (gpio_is_valid(ddata->pd_gpio))
> - gpio_set_value(ddata->pd_gpio, 1);
> + gpio_set_value_cansleep(ddata->pd_gpio, 1);
>
> return 0;
> err0:
> @@ -83,7 +83,7 @@ static void tfp410_power_off(struct omap_dss_device *dssdev)
> return;
>
> if (gpio_is_valid(ddata->pd_gpio))
> - gpio_set_value(ddata->pd_gpio, 0);
> + gpio_set_value_cansleep(ddata->pd_gpio, 0);
>
> omapdss_dpi_display_disable(dssdev);
> }
> --
> 1.7.10
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Russ Dill @ 2012-05-09 22:08 UTC (permalink / raw)
To: linux-omap; +Cc: linux-fbdev, Russ Dill
The Beagleboard xM gpio used for TFP410 powerdown is connected through
an I2C attached chip which means setting the GPIO can sleep. Code that
calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
---
drivers/video/omap2/displays/panel-tfp410.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
index 52637fa..1266520 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -68,7 +68,7 @@ static int tfp410_power_on(struct omap_dss_device *dssdev)
goto err0;
if (gpio_is_valid(ddata->pd_gpio))
- gpio_set_value(ddata->pd_gpio, 1);
+ gpio_set_value_cansleep(ddata->pd_gpio, 1);
return 0;
err0:
@@ -83,7 +83,7 @@ static void tfp410_power_off(struct omap_dss_device *dssdev)
return;
if (gpio_is_valid(ddata->pd_gpio))
- gpio_set_value(ddata->pd_gpio, 0);
+ gpio_set_value_cansleep(ddata->pd_gpio, 0);
omapdss_dpi_display_disable(dssdev);
}
--
1.7.10
^ permalink raw reply related
* Re: [PATCH 01/25] OMAPDSS: panel-dvi: add PD gpio handling
From: Tomi Valkeinen @ 2012-05-09 17:32 UTC (permalink / raw)
To: Russ Dill; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <CA+Bv8XZSpBJ4_DD=uTkX1zD+Hj31MehCVATjNKo0Bo4aHUfnNA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]
On Wed, 2012-05-09 at 09:50 -0700, Russ Dill wrote:
> On Thu, May 3, 2012 at 6:57 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > The driver for the TFP410 chip should handle the power-down signal of
> > the chip, instead of the current way of handling it in the board files.
> >
> > This patch adds power_down_gpio into the device's platform data, and
> > adds the necessary code in the driver to request and handle the GPIO.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > ---
> > drivers/video/omap2/displays/panel-dvi.c | 31 ++++++++++++++++++++++++++++++
> > include/video/omap-panel-dvi.h | 2 ++
> > 2 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/video/omap2/displays/panel-dvi.c b/drivers/video/omap2/displays/panel-dvi.c
> > index 03eb14a..876b798 100644
> > --- a/drivers/video/omap2/displays/panel-dvi.c
> > +++ b/drivers/video/omap2/displays/panel-dvi.c
> > @@ -21,6 +21,7 @@
> > #include <linux/slab.h>
> > #include <video/omapdss.h>
> > #include <linux/i2c.h>
> > +#include <linux/gpio.h>
> > #include <drm/drm_edid.h>
> >
> > #include <video/omap-panel-dvi.h>
> > @@ -44,6 +45,8 @@ struct panel_drv_data {
> > struct omap_dss_device *dssdev;
> >
> > struct mutex lock;
> > +
> > + int pd_gpio;
> > };
> >
> > static inline struct panel_dvi_platform_data
> > @@ -54,6 +57,7 @@ static inline struct panel_dvi_platform_data
> >
> > static int panel_dvi_power_on(struct omap_dss_device *dssdev)
> > {
> > + struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> > struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
> > int r;
> >
> > @@ -70,6 +74,9 @@ static int panel_dvi_power_on(struct omap_dss_device *dssdev)
> > goto err1;
> > }
> >
> > + if (gpio_is_valid(ddata->pd_gpio))
> > + gpio_set_value(ddata->pd_gpio, 1);
> > +
>
> On Beagleboard xM, this GPIO is connected though an I2C chip so it
> sleeps. Can you change these to gpio_set_value_cansleep?
This patch has already been applied, so we have to do follow up patches
for this. I can look at this tomorrow, but if you update your "ARM:
OMAP: Cleanup Beagleboard DVI reset gpio" patch, will you take a look at
this also?
The applied patches can be found from here, so the follow up patches
should be based on this: git://gitorious.org/linux-omap-dss2/linux.git
for-l-o-3.5
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 01/25] OMAPDSS: panel-dvi: add PD gpio handling
From: Russ Dill @ 2012-05-09 16:50 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1336053481-25433-2-git-send-email-tomi.valkeinen@ti.com>
On Thu, May 3, 2012 at 6:57 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> The driver for the TFP410 chip should handle the power-down signal of
> the chip, instead of the current way of handling it in the board files.
>
> This patch adds power_down_gpio into the device's platform data, and
> adds the necessary code in the driver to request and handle the GPIO.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/displays/panel-dvi.c | 31 ++++++++++++++++++++++++++++++
> include/video/omap-panel-dvi.h | 2 ++
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/video/omap2/displays/panel-dvi.c b/drivers/video/omap2/displays/panel-dvi.c
> index 03eb14a..876b798 100644
> --- a/drivers/video/omap2/displays/panel-dvi.c
> +++ b/drivers/video/omap2/displays/panel-dvi.c
> @@ -21,6 +21,7 @@
> #include <linux/slab.h>
> #include <video/omapdss.h>
> #include <linux/i2c.h>
> +#include <linux/gpio.h>
> #include <drm/drm_edid.h>
>
> #include <video/omap-panel-dvi.h>
> @@ -44,6 +45,8 @@ struct panel_drv_data {
> struct omap_dss_device *dssdev;
>
> struct mutex lock;
> +
> + int pd_gpio;
> };
>
> static inline struct panel_dvi_platform_data
> @@ -54,6 +57,7 @@ static inline struct panel_dvi_platform_data
>
> static int panel_dvi_power_on(struct omap_dss_device *dssdev)
> {
> + struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
> int r;
>
> @@ -70,6 +74,9 @@ static int panel_dvi_power_on(struct omap_dss_device *dssdev)
> goto err1;
> }
>
> + if (gpio_is_valid(ddata->pd_gpio))
> + gpio_set_value(ddata->pd_gpio, 1);
> +
On Beagleboard xM, this GPIO is connected though an I2C chip so it
sleeps. Can you change these to gpio_set_value_cansleep?
> return 0;
> err1:
> omapdss_dpi_display_disable(dssdev);
> @@ -79,11 +86,15 @@ err0:
>
> static void panel_dvi_power_off(struct omap_dss_device *dssdev)
> {
> + struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
> struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
>
> if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
> return;
>
> + if (gpio_is_valid(ddata->pd_gpio))
> + gpio_set_value(ddata->pd_gpio, 0);
> +
Same with this one.
> if (pdata->platform_disable)
> pdata->platform_disable(dssdev);
>
> @@ -92,7 +103,9 @@ static void panel_dvi_power_off(struct omap_dss_device *dssdev)
>
> static int panel_dvi_probe(struct omap_dss_device *dssdev)
> {
> + struct panel_dvi_platform_data *pdata = get_pdata(dssdev);
> struct panel_drv_data *ddata;
> + int r;
>
> ddata = kzalloc(sizeof(*ddata), GFP_KERNEL);
> if (!ddata)
> @@ -104,6 +117,21 @@ static int panel_dvi_probe(struct omap_dss_device *dssdev)
> ddata->dssdev = dssdev;
> mutex_init(&ddata->lock);
>
> + if (pdata)
> + ddata->pd_gpio = pdata->power_down_gpio;
> + else
> + ddata->pd_gpio = -1;
> +
> + if (gpio_is_valid(ddata->pd_gpio)) {
> + r = gpio_request_one(ddata->pd_gpio, GPIOF_OUT_INIT_LOW,
> + "tfp410 pd");
> + if (r) {
> + dev_err(&dssdev->dev, "Failed to request PD GPIO %d\n",
> + ddata->pd_gpio);
> + ddata->pd_gpio = -1;
> + }
> + }
> +
> dev_set_drvdata(&dssdev->dev, ddata);
>
> return 0;
> @@ -115,6 +143,9 @@ static void __exit panel_dvi_remove(struct omap_dss_device *dssdev)
>
> mutex_lock(&ddata->lock);
>
> + if (gpio_is_valid(ddata->pd_gpio))
> + gpio_free(ddata->pd_gpio);
> +
> dev_set_drvdata(&dssdev->dev, NULL);
>
> mutex_unlock(&ddata->lock);
> diff --git a/include/video/omap-panel-dvi.h b/include/video/omap-panel-dvi.h
> index 87ad567b..4ad41fc 100644
> --- a/include/video/omap-panel-dvi.h
> +++ b/include/video/omap-panel-dvi.h
> @@ -27,11 +27,13 @@ struct omap_dss_device;
> * @platform_enable: platform specific panel enable function
> * @platform_disable: platform specific panel disable function
> * @i2c_bus_num: i2c bus id for the panel
> + * @power_down_gpio: gpio number for PD pin (or -1 if not available)
> */
> struct panel_dvi_platform_data {
> int (*platform_enable)(struct omap_dss_device *dssdev);
> void (*platform_disable)(struct omap_dss_device *dssdev);
> u16 i2c_bus_num;
> + int power_down_gpio;
> };
>
> #endif /* __OMAP_PANEL_DVI_H */
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
From: Tony Lindgren @ 2012-05-09 15:45 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1336550949.3962.2.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120509 01:12]:
>
> Below is the pull request for board file related changes. Tested on
> panda & 4430sdp.
Thanks, I've merged that into clenaup-dss branch and will send it
along with other still pending cleanup branches.
> How should I manage my tree related to this... Should I rebase my
> original DT preparation series on top of this new branch, or can I just
> ignore the new branch for now, as long as I merge it at some point
> before sending a pull request to mainline?
Yes you need to rebase on this now. And not touch these commits.
Otherwise we'll end up with duplicate commits in the mainline tree,
which is a big no-no. If something shows up that needs fixing in this
series, it must now be separate patches on top of this series.
When doing pull requests we both just have to make note that there's
a dependency to this branch, and it will find it's way to mainline
via arm-soc pull request. Or if no conflicts need sorting out, then
it will just get merged with your pull request.
Regards,
Tony
> Tomi
>
> The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:
>
> Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)
>
> are available in the git repository at:
>
> git://gitorious.org/linux-omap-dss2/linux.git for-l-o-3.5
>
> for you to fetch changes up to e4a9e94cc58ed6e4efb02b80be3a9bf57f448d07:
>
> OMAPDSS: DSI: implement generic DSI pin config (2012-05-09 10:53:05 +0300)
>
> ----------------------------------------------------------------
> Tomi Valkeinen (6):
> OMAPDSS: panel-dvi: add PD gpio handling
> OMAP: board-files: remove custom PD GPIO handling for DVI output
> OMAPDSS: TFP410: rename dvi -> tfp410
> OMAPDSS: TFP410: rename dvi files to tfp410
> OMAPDSS: Taal: move reset gpio handling to taal driver
> OMAPDSS: DSI: implement generic DSI pin config
>
> arch/arm/mach-omap2/board-3430sdp.c | 38 +-----
> arch/arm/mach-omap2/board-4430sdp.c | 37 ++----
> arch/arm/mach-omap2/board-am3517evm.c | 25 +---
> arch/arm/mach-omap2/board-cm-t35.c | 30 +----
> arch/arm/mach-omap2/board-devkit8000.c | 30 +----
> arch/arm/mach-omap2/board-igep0020.c | 32 +----
> arch/arm/mach-omap2/board-omap3beagle.c | 37 +-----
> arch/arm/mach-omap2/board-omap3evm.c | 29 +----
> arch/arm/mach-omap2/board-omap3stalker.c | 29 +----
> arch/arm/mach-omap2/board-omap4panda.c | 39 +-----
> arch/arm/mach-omap2/board-overo.c | 25 +---
> drivers/video/omap2/displays/Kconfig | 8 +-
> drivers/video/omap2/displays/Makefile | 2 +-
> drivers/video/omap2/displays/panel-taal.c | 22 ++++
> .../omap2/displays/{panel-dvi.c => panel-tfp410.c} | 134 +++++++++++---------
> drivers/video/omap2/dss/dsi.c | 133 +++++++++----------
> include/video/omap-panel-nokia-dsi.h | 3 +
> .../{omap-panel-dvi.h => omap-panel-tfp410.h} | 18 ++-
> include/video/omapdss.h | 28 ++--
> 19 files changed, 251 insertions(+), 448 deletions(-)
> rename drivers/video/omap2/displays/{panel-dvi.c => panel-tfp410.c} (63%)
> rename include/video/{omap-panel-dvi.h => omap-panel-tfp410.h} (63%)
>
^ permalink raw reply
* Re: [PATCH v2 1/4] mfd: add LM3533 lighting-power core driver
From: Samuel Ortiz @ 2012-05-09 14:42 UTC (permalink / raw)
To: Johan Hovold
Cc: Rob Landley, Richard Purdie, Jonathan Cameron, Greg Kroah-Hartman,
Florian Tobias Schandinat, Arnd Bergmann, Andrew Morton,
Mark Brown, linux-doc, linux-kernel, linux-iio, devel,
linux-fbdev
In-Reply-To: <1336040799-18433-2-git-send-email-jhovold@gmail.com>
Hi Johan
On Thu, May 03, 2012 at 12:26:36PM +0200, Johan Hovold wrote:
> Add support for National Semiconductor / TI LM3533 lighting power chips.
>
> This is the core driver which provides register access over I2C and
> registers the ambient-light-sensor, LED and backlight sub-drivers.
>
> Signed-off-by: Johan Hovold <jhovold@gmail.com>
> ---
>
> v2:
> - add sysfs-ABI documentation
> - merge i2c implementation with core
> - use regmap and kill custom debugfs interface
>
>
> .../ABI/testing/sysfs-bus-i2c-devices-lm3533 | 38 +
> drivers/mfd/Kconfig | 13 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/lm3533-core.c | 717 ++++++++++++++++++++
> drivers/mfd/lm3533-ctrlbank.c | 134 ++++
> include/linux/mfd/lm3533.h | 89 +++
> 6 files changed, 992 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533
> create mode 100644 drivers/mfd/lm3533-core.c
> create mode 100644 drivers/mfd/lm3533-ctrlbank.c
> create mode 100644 include/linux/mfd/lm3533.h
Patch applied to my for-next branch, thanks.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH v4 0/9] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
From: Tomi Valkeinen @ 2012-05-09 11:51 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4FAA53EA.7040400@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]
On Wed, 2012-05-09 at 16:54 +0530, Archit Taneja wrote:
> On Wednesday 09 May 2012 04:43 PM, Tomi Valkeinen wrote:
> > On Wed, 2012-05-09 at 15:40 +0530, Archit Taneja wrote:
> >> An overlay manager's timings (the manager size, and blanking parameters if an
> >> LCD manager) are DISPC shadow registers, and they should hence follow the
> >> correct programming model.
> >>
> >> This set makes the timings an extra_info parameter in manager's private data .
> >> The interface drivers now apply the timings in instead of directly writing to
> >> registers.
> >>
> >> This change also prevents the need to use display resolution for overlay
> >> checks, hence making some of the APPLY functions less dependent on the display.
> >> Some DISPC functions that needed display width can also use these privately
> >> stored timings.
> >>
> >> Changes since v3:
> >>
> >> - Remove direct setting of go bit in dpi_set_timings()
> >> - Take some of the patches in "OMAPDSS: Misc fixes and cleanups" and make them a
> >> part of this series as they are more related.
> >> - Don't have an initial set of manager timings in private data, only check
> >> manager and overlay parameters once the manager is enabled.
> >>
> >> These patches apply over:
> >>
> >> git://gitorious.org/linux-omap-dss2/linux.git dev
> >>
> >> Reference tree containing this series:
> >>
> >> git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes_2
> >>
> >> Tested on OMAP4 SDP and Panda.
> >
> > I did some quick tests on omap3 overo, worked fine. I'll merge to dss
> > master branch.
>
> Russ did some tests on more omap3 boards, the tree which he used has
> some slight changes comapred to what I have posted, but it's more or
> less the same.
>
> Could you add 'Tested-by: Russ.Dill@ti.com' if not too difficult, I
> missed out doing that.
Sorry, I could, but I already merged and pushed the series, so I can't
change it anymore.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/9] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
From: Archit Taneja @ 2012-05-09 11:36 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336561991.3962.31.camel@deskari>
On Wednesday 09 May 2012 04:43 PM, Tomi Valkeinen wrote:
> On Wed, 2012-05-09 at 15:40 +0530, Archit Taneja wrote:
>> An overlay manager's timings (the manager size, and blanking parameters if an
>> LCD manager) are DISPC shadow registers, and they should hence follow the
>> correct programming model.
>>
>> This set makes the timings an extra_info parameter in manager's private data .
>> The interface drivers now apply the timings in instead of directly writing to
>> registers.
>>
>> This change also prevents the need to use display resolution for overlay
>> checks, hence making some of the APPLY functions less dependent on the display.
>> Some DISPC functions that needed display width can also use these privately
>> stored timings.
>>
>> Changes since v3:
>>
>> - Remove direct setting of go bit in dpi_set_timings()
>> - Take some of the patches in "OMAPDSS: Misc fixes and cleanups" and make them a
>> part of this series as they are more related.
>> - Don't have an initial set of manager timings in private data, only check
>> manager and overlay parameters once the manager is enabled.
>>
>> These patches apply over:
>>
>> git://gitorious.org/linux-omap-dss2/linux.git dev
>>
>> Reference tree containing this series:
>>
>> git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes_2
>>
>> Tested on OMAP4 SDP and Panda.
>
> I did some quick tests on omap3 overo, worked fine. I'll merge to dss
> master branch.
Russ did some tests on more omap3 boards, the tree which he used has
some slight changes comapred to what I have posted, but it's more or
less the same.
Could you add 'Tested-by: Russ.Dill@ti.com' if not too difficult, I
missed out doing that.
Thanks,
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH v4 0/9] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
From: Tomi Valkeinen @ 2012-05-09 11:13 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336558256-26140-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
On Wed, 2012-05-09 at 15:40 +0530, Archit Taneja wrote:
> An overlay manager's timings (the manager size, and blanking parameters if an
> LCD manager) are DISPC shadow registers, and they should hence follow the
> correct programming model.
>
> This set makes the timings an extra_info parameter in manager's private data .
> The interface drivers now apply the timings in instead of directly writing to
> registers.
>
> This change also prevents the need to use display resolution for overlay
> checks, hence making some of the APPLY functions less dependent on the display.
> Some DISPC functions that needed display width can also use these privately
> stored timings.
>
> Changes since v3:
>
> - Remove direct setting of go bit in dpi_set_timings()
> - Take some of the patches in "OMAPDSS: Misc fixes and cleanups" and make them a
> part of this series as they are more related.
> - Don't have an initial set of manager timings in private data, only check
> manager and overlay parameters once the manager is enabled.
>
> These patches apply over:
>
> git://gitorious.org/linux-omap-dss2/linux.git dev
>
> Reference tree containing this series:
>
> git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes_2
>
> Tested on OMAP4 SDP and Panda.
I did some quick tests on omap3 overo, worked fine. I'll merge to dss
master branch.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH v4 9/9] OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
From: Archit Taneja @ 2012-05-09 10:22 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1336558256-26140-1-git-send-email-archit@ti.com>
The functions calc_fclk_five_taps() and check_horiz_timing_omap3() use the
function dispc_mgr_get_device() to get the omap_dss_device pointer to which
the manager is connected, the width of the panel is derived from it.
The manager's timing is stored in it's private data in APPLY. This contains
the latest timings applied to the manager. Pass these timings to
dispc_ovl_setup() and use them in the above functions. Remove the function
dispc_mgr_get_device() as it isn't used any more.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/apply.c | 6 ++--
drivers/video/omap2/dss/dispc.c | 51 +++++++++++++++++---------------------
drivers/video/omap2/dss/dss.h | 3 +-
3 files changed, 28 insertions(+), 32 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 15c070c..dd88b8f 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -548,11 +548,13 @@ static void dss_ovl_write_regs(struct omap_overlay *ovl)
oi = &op->info;
+ mp = get_mgr_priv(ovl->manager);
+
replication = dss_use_replication(ovl->manager->device, oi->color_mode);
ilace = ovl->manager->device->type = OMAP_DISPLAY_TYPE_VENC;
- r = dispc_ovl_setup(ovl->id, oi, ilace, replication);
+ r = dispc_ovl_setup(ovl->id, oi, ilace, replication, &mp->timings);
if (r) {
/*
* We can't do much here, as this function can be called from
@@ -566,8 +568,6 @@ static void dss_ovl_write_regs(struct omap_overlay *ovl)
return;
}
- mp = get_mgr_priv(ovl->manager);
-
op->info_dirty = false;
if (mp->updating)
op->shadow_info_dirty = true;
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index cd0a397..727e15b 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -413,14 +413,6 @@ static inline bool dispc_mgr_is_lcd(enum omap_channel channel)
return false;
}
-static struct omap_dss_device *dispc_mgr_get_device(enum omap_channel channel)
-{
- struct omap_overlay_manager *mgr - omap_dss_get_overlay_manager(channel);
-
- return mgr ? mgr->device : NULL;
-}
-
u32 dispc_mgr_get_vsync_irq(enum omap_channel channel)
{
switch (channel) {
@@ -1661,18 +1653,17 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
* This function is used to avoid synclosts in OMAP3, because of some
* undocumented horizontal position and timing related limitations.
*/
-static int check_horiz_timing_omap3(enum omap_channel channel, u16 pos_x,
+static int check_horiz_timing_omap3(enum omap_channel channel,
+ const struct omap_video_timings *t, u16 pos_x,
u16 width, u16 height, u16 out_width, u16 out_height)
{
int DS = DIV_ROUND_UP(height, out_height);
- struct omap_dss_device *dssdev = dispc_mgr_get_device(channel);
- struct omap_video_timings t = dssdev->panel.timings;
unsigned long nonactive, lclk, pclk;
static const u8 limits[3] = { 8, 10, 20 };
u64 val, blank;
int i;
- nonactive = t.x_res + t.hfp + t.hsw + t.hbp - out_width;
+ nonactive = t->x_res + t->hfp + t->hsw + t->hbp - out_width;
pclk = dispc_mgr_pclk_rate(channel);
if (dispc_mgr_is_lcd(channel))
lclk = dispc_mgr_lclk_rate(channel);
@@ -1684,7 +1675,7 @@ static int check_horiz_timing_omap3(enum omap_channel channel, u16 pos_x,
i++;
if (out_width < width)
i++;
- blank = div_u64((u64)(t.hbp + t.hsw + t.hfp) * lclk, pclk);
+ blank = div_u64((u64)(t->hbp + t->hsw + t->hfp) * lclk, pclk);
DSSDBG("blanking period + ppl = %llu (limit = %u)\n", blank, limits[i]);
if (blank <= limits[i])
return -EINVAL;
@@ -1715,7 +1706,8 @@ static int check_horiz_timing_omap3(enum omap_channel channel, u16 pos_x,
}
static unsigned long calc_core_clk_five_taps(enum omap_channel channel,
- u16 width, u16 height, u16 out_width, u16 out_height,
+ const struct omap_video_timings *mgr_timings, u16 width,
+ u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode)
{
u32 core_clk = 0;
@@ -1725,8 +1717,7 @@ static unsigned long calc_core_clk_five_taps(enum omap_channel channel,
return (unsigned long) pclk;
if (height > out_height) {
- struct omap_dss_device *dssdev = dispc_mgr_get_device(channel);
- unsigned int ppl = dssdev->panel.timings.x_res;
+ unsigned int ppl = mgr_timings->x_res;
tmp = pclk * height * out_width;
do_div(tmp, 2 * out_height * ppl);
@@ -1795,8 +1786,9 @@ static unsigned long calc_core_clk(enum omap_channel channel, u16 width,
}
static int dispc_ovl_calc_scaling(enum omap_plane plane,
- enum omap_channel channel, u16 width, u16 height,
- u16 out_width, u16 out_height,
+ enum omap_channel channel,
+ const struct omap_video_timings *mgr_timings,
+ u16 width, u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
int *x_predecim, int *y_predecim, u16 pos_x)
{
@@ -1871,11 +1863,13 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
do {
in_height = DIV_ROUND_UP(height, decim_y);
in_width = DIV_ROUND_UP(width, decim_x);
- core_clk = calc_core_clk_five_taps(channel, in_width,
- in_height, out_width, out_height, color_mode);
+ core_clk = calc_core_clk_five_taps(channel, mgr_timings,
+ in_width, in_height, out_width, out_height,
+ color_mode);
- error = check_horiz_timing_omap3(channel, pos_x,
- in_width, in_height, out_width, out_height);
+ error = check_horiz_timing_omap3(channel, mgr_timings,
+ pos_x, in_width, in_height, out_width,
+ out_height);
if (in_width > maxsinglelinewidth)
if (in_height > out_height &&
@@ -1900,8 +1894,8 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
} while (decim_x <= *x_predecim && decim_y <= *y_predecim
&& error);
- if (check_horiz_timing_omap3(channel, pos_x, width, height,
- out_width, out_height)){
+ if (check_horiz_timing_omap3(channel, mgr_timings, pos_x, width,
+ height, out_width, out_height)){
DSSERR("horizontal timing too tight\n");
return -EINVAL;
}
@@ -1959,7 +1953,8 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
}
int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
- bool ilace, bool replication)
+ bool ilace, bool replication,
+ const struct omap_video_timings *mgr_timings)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
bool five_taps = true;
@@ -2008,9 +2003,9 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
if (!dss_feat_color_mode_supported(plane, oi->color_mode))
return -EINVAL;
- r = dispc_ovl_calc_scaling(plane, channel, in_width, in_height,
- out_width, out_height, oi->color_mode, &five_taps,
- &x_predecim, &y_predecim, oi->pos_x);
+ r = dispc_ovl_calc_scaling(plane, channel, mgr_timings, in_width,
+ in_height, out_width, out_height, oi->color_mode,
+ &five_taps, &x_predecim, &y_predecim, oi->pos_x);
if (r)
return r;
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index f3fa445..8e9e9a5 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -428,7 +428,8 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high);
void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane,
u32 *fifo_low, u32 *fifo_high, bool use_fifomerge);
int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
- bool ilace, bool replication);
+ bool ilace, bool replication,
+ const struct omap_video_timings *mgr_timings);
int dispc_ovl_enable(enum omap_plane plane, bool enable);
void dispc_ovl_set_channel_out(enum omap_plane plane,
enum omap_channel channel);
--
1.7.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox