* [PATCH] coding style: Fix 1 error and 5 warnings
From: antoine @ 2015-07-16 15:55 UTC (permalink / raw)
To: linux-fbdev
This is a patch to the ddk750_power.c file that fixes up five "line over 80
characters" warnings and one "return is not a function, parentheses are not
required" error found by the checkpatch.pl script.
Signed-off-by: Antoine BLIN <antoine.blin@lip6.fr>
---
drivers/staging/sm750fb/ddk750_power.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_power.c b/drivers/staging/sm750fb/ddk750_power.c
index c8c51be..42961ea 100644
--- a/drivers/staging/sm750fb/ddk750_power.c
+++ b/drivers/staging/sm750fb/ddk750_power.c
@@ -8,7 +8,8 @@ void ddk750_setDPMS(DPMS_t state)
if (getChipType() = SM750LE) {
value = PEEK32(CRT_DISPLAY_CTRL);
- POKE32(CRT_DISPLAY_CTRL, FIELD_VALUE(value, CRT_DISPLAY_CTRL, DPMS, state));
+ POKE32(CRT_DISPLAY_CTRL, FIELD_VALUE(value, CRT_DISPLAY_CTRL,
+ DPMS, state));
} else {
value = PEEK32(SYSTEM_CTRL);
value = FIELD_VALUE(value, SYSTEM_CTRL, DPMS, state);
@@ -20,7 +21,7 @@ unsigned int getPowerMode(void)
{
if (getChipType() = SM750LE)
return 0;
- return (FIELD_GET(PEEK32(POWER_MODE_CTRL), POWER_MODE_CTRL, MODE));
+ return FIELD_GET(PEEK32(POWER_MODE_CTRL), POWER_MODE_CTRL, MODE);
}
@@ -39,15 +40,18 @@ void setPowerMode(unsigned int powerMode)
switch (powerMode) {
case POWER_MODE_CTRL_MODE_MODE0:
- control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE, MODE0);
+ control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE,
+ MODE0);
break;
case POWER_MODE_CTRL_MODE_MODE1:
- control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE, MODE1);
+ control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE,
+ MODE1);
break;
case POWER_MODE_CTRL_MODE_SLEEP:
- control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE, SLEEP);
+ control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE,
+ SLEEP);
break;
default:
@@ -138,8 +142,9 @@ void enableZVPort(unsigned int enable)
gate = FIELD_SET(gate, CURRENT_GATE, I2C, ON);
#endif
} else {
- /* Disable ZV Port Gate. There is no way to know whether the GPIO pins are being used
- or not. Therefore, do not disable the GPIO gate. */
+ /* Disable ZV Port Gate. There is no way to know whether the
+ GPIO pins are being used or not. Therefore, do not disable the
+ GPIO gate. */
gate = FIELD_SET(gate, CURRENT_GATE, ZVPORT, OFF);
}
--
2.4.5
^ permalink raw reply related
* Re: [PATCH v2] staging: sm750fb: ddk750_chip: use consistent spacing
From: Greg KH @ 2015-07-16 17:15 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1436939719-386-1-git-send-email-shshahu@gmail.com>
On Wed, Jul 15, 2015 at 11:25:19AM +0530, Sunil Shahu wrote:
> Remove all checkpatch error by using consistent spacing.
>
> Signed-off-by: Sunil Shahu <shshahu@gmail.com>
> ---
> drivers/staging/sm750fb/ddk750_chip.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
This doesn't apply to my tree :(
^ permalink raw reply
* Re: [PATCH v2 01/12] device: property: delay device-driver matches
From: Mark Brown @ 2015-07-16 20:23 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: linux-kernel, linux-acpi, dri-devel, linux-fbdev, linux-gpio,
devicetree, linux-pwm, Rafael J. Wysocki, alsa-devel,
Greg Kroah-Hartman
In-Reply-To: <1435743667-11987-2-git-send-email-tomeu.vizoso@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
On Wed, Jul 01, 2015 at 11:40:56AM +0200, Tomeu Vizoso wrote:
> Delay matches of platform devices until late_initcall, when we are sure
> that all built-in drivers have been registered already. This is needed
> to prevent deferred probes because of some dependencies' drivers not
> having registered yet.
I have to say I'm still not 100% clear that special casing platform
devices makes sense here - I can see that platform devices are usually
the first devices to instantiate but there are other kinds of devices
and it's not obvious what the benefit of specifically picking out
platform devices as opposed to just deferring all devices is.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH v2 09/12] regulator: register dependency parser for firmware nodes
From: Mark Brown @ 2015-07-16 21:38 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: linux-kernel, linux-acpi, dri-devel, linux-fbdev, linux-gpio,
devicetree, linux-pwm, Rafael J. Wysocki, alsa-devel,
Liam Girdwood
In-Reply-To: <1435743667-11987-10-git-send-email-tomeu.vizoso@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
On Wed, Jul 01, 2015 at 11:41:04AM +0200, Tomeu Vizoso wrote:
> So others can find out what depends on regulators, as specified
> in bindings/regulator/regulator.txt.
Reviewed-by: Mark Brown <broonie@kernel.org>
from a regulator point of view.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 11/12] ASoC: tegra: register dependency parser for firmware nodes
From: Mark Brown @ 2015-07-16 23:04 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: devicetree@vger.kernel.org, linux-fbdev, linux-acpi, alsa-devel,
Stephen Warren, Takashi Iwai, Rafael J. Wysocki, Liam Girdwood,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-gpio, Thierry Reding, Linux PWM List,
linux-tegra@vger.kernel.org, Alexandre Courbot
In-Reply-To: <CAAObsKAHviKKTrEBhuge-KQ115p-kOf69miNnmpR+7knOeg+qg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]
On Tue, Jul 14, 2015 at 02:47:04PM +0200, Tomeu Vizoso wrote:
> On 14 July 2015 at 13:07, Mark Brown <broonie@kernel.org> wrote:
> > I'm not sure how I can be clearer here... you're replacing something
> > that is currently pure data with open coding in each device. That seems
> > like a step back in terms of ease of use.
> I could understand that if snd_soc_dai_link had a field with the
> property name, and the core called of_parse_phandle on it, but
> currently what I'm duplicating is:
> tegra_max98090_dai.cpu_of_node = of_parse_phandle(np,
> "nvidia,i2s-controller", 0);
> with:
> add_dependency(fwnode, "nvidia,i2s-controller", deps);
> Admittedly, we could add a cpu_fw_property field to snd_soc_dai_link
> and have the core call of_parse_phandle itself.
Yes, we could - that's really what should be happening here. The other
bit of this is that we're doing it twice which isn't success.
> But even then, the core doesn't know about a device's snd_soc_dai_link
> until probe() is called and then it's too late for the purposes of
> this series.
That's not a good reason to encourage bad patterns in drivers. At the
very least the drivers should be able to pass the same struct into both
places, having to open code the same thing in two places is going to be
error prone.
> That's why I mentioned devm_probe, as it would add a common way to
> specify the data needed to acquire resources in each driver, which
> could be made available before probe() is called.
That does avoid the duplication. However there are issues with the
interface for enumerable buses, it doesn't solve the problem where
embedded systems need you to power up the device manually prior to the
device actually enumerating. If we're doing early resource acquisition
we probably want to solve that too.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/12] device: property: delay device-driver matches
From: Rafael J. Wysocki @ 2015-07-16 23:41 UTC (permalink / raw)
To: Mark Brown
Cc: Tomeu Vizoso, Linux Kernel Mailing List, ACPI Devel Maling List,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, Rafael J. Wysocki,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Greg Kroah-Hartman
In-Reply-To: <20150716202312.GD11162-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
Hi Mark,
On Thu, Jul 16, 2015 at 10:23 PM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Jul 01, 2015 at 11:40:56AM +0200, Tomeu Vizoso wrote:
>
>> Delay matches of platform devices until late_initcall, when we are sure
>> that all built-in drivers have been registered already. This is needed
>> to prevent deferred probes because of some dependencies' drivers not
>> having registered yet.
>
> I have to say I'm still not 100% clear that special casing platform
> devices makes sense here - I can see that platform devices are usually
> the first devices to instantiate but there are other kinds of devices
> and it's not obvious what the benefit of specifically picking out
> platform devices as opposed to just deferring all devices is.
Some existing devices cannot be deferred without redesigning things quite a bit.
What I was talking about, though, was to use an opt-in mechanism for
that which could be set for all platform devices, for example, by
default, but it might be set for other bus types too if that's useful.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH v2 01/12] device: property: delay device-driver matches
From: Mark Brown @ 2015-07-17 0:06 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Tomeu Vizoso, Linux Kernel Mailing List, ACPI Devel Maling List,
dri-devel, linux-fbdev, linux-gpio, devicetree@vger.kernel.org,
linux-pwm, Rafael J. Wysocki, alsa-devel, Greg Kroah-Hartman
In-Reply-To: <CAJZ5v0gMx=DA0f8i9wdMvkYTyOhr0WKh-T6L7rjcxeaAjNMW3g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]
On Fri, Jul 17, 2015 at 01:41:16AM +0200, Rafael J. Wysocki wrote:
> On Thu, Jul 16, 2015 at 10:23 PM, Mark Brown <broonie@kernel.org> wrote:
> > On Wed, Jul 01, 2015 at 11:40:56AM +0200, Tomeu Vizoso wrote:
> > I have to say I'm still not 100% clear that special casing platform
> > devices makes sense here - I can see that platform devices are usually
> > the first devices to instantiate but there are other kinds of devices
> > and it's not obvious what the benefit of specifically picking out
> > platform devices as opposed to just deferring all devices is.
> Some existing devices cannot be deferred without redesigning things quite a bit.
OK, that should go in the changelog then - right now it's just a bit
obtuse why we're doing this (and as you say it's a bit awkward). Now
you mention this I'm thinking that some of the affected devices might be
platform devices on some systems, IOMMUs spring to mind for example...
they're one of the main bits of the system I'm aware of that still rely
on probe ordering and they do tend to be platform devices.
> What I was talking about, though, was to use an opt-in mechanism for
> that which could be set for all platform devices, for example, by
> default, but it might be set for other bus types too if that's useful.
Sure, I got that and do agree with you that a mechanism like you suggest
would be good. I just wasn't clear why we were targetting platform
devices in the first place.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* [PATCH] staging: sm750fb: removed extra parentheses
From: Aaron Ouellette @ 2015-07-17 1:21 UTC (permalink / raw)
To: linux-fbdev
fixed checkpatch.pl error:
ERROR: return is not a function, parentheses are not needed
Signed-off-by: Aaron Ouellette <aouellette2016@gmail.com>
---
drivers/staging/sm750fb/ddk750_power.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/sm750fb/ddk750_power.c b/drivers/staging/sm750fb/ddk750_power.c
index c8c51be..3c04447 100644
--- a/drivers/staging/sm750fb/ddk750_power.c
+++ b/drivers/staging/sm750fb/ddk750_power.c
@@ -20,7 +20,7 @@ unsigned int getPowerMode(void)
{
if (getChipType() = SM750LE)
return 0;
- return (FIELD_GET(PEEK32(POWER_MODE_CTRL), POWER_MODE_CTRL, MODE));
+ return FIELD_GET(PEEK32(POWER_MODE_CTRL), POWER_MODE_CTRL, MODE);
}
--
2.4.6
^ permalink raw reply related
* Re: [PATCH] coding style: Fix 1 error and 5 warnings
From: Sudip Mukherjee @ 2015-07-17 5:34 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1437062154-29181-1-git-send-email-antoine.blin@lip6.fr>
On Thu, Jul 16, 2015 at 05:55:54PM +0200, antoine wrote:
> This is a patch to the ddk750_power.c file that fixes up five "line over 80
> characters" warnings and one "return is not a function, parentheses are not
> required" error found by the checkpatch.pl script.
That becomes two different change. Please only do one type of change in
one patch.
>
> Signed-off-by: Antoine BLIN <antoine.blin@lip6.fr>
Your Signed-off-by name should match your email From: header. Please
make the required changed in your .gitconfig file.
> ---
> drivers/staging/sm750fb/ddk750_power.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_power.c b/drivers/staging/sm750fb/ddk750_power.c
> index c8c51be..42961ea 100644
> --- a/drivers/staging/sm750fb/ddk750_power.c
> +++ b/drivers/staging/sm750fb/ddk750_power.c
> @@ -8,7 +8,8 @@ void ddk750_setDPMS(DPMS_t state)
>
> if (getChipType() = SM750LE) {
> value = PEEK32(CRT_DISPLAY_CTRL);
> - POKE32(CRT_DISPLAY_CTRL, FIELD_VALUE(value, CRT_DISPLAY_CTRL, DPMS, state));
> + POKE32(CRT_DISPLAY_CTRL, FIELD_VALUE(value, CRT_DISPLAY_CTRL,
> + DPMS, state));
Check your patch with --strict option of checkpatch and it will say
"alignment not matching"
regards
sudip
^ permalink raw reply
* Re: [PATCH] coding style: Fix 1 error and 5 warnings
From: Sudip Mukherjee @ 2015-07-17 5:44 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1437062154-29181-1-git-send-email-antoine.blin@lip6.fr>
On Fri, Jul 17, 2015 at 10:52:59AM +0530, Sudip Mukherjee wrote:
> On Thu, Jul 16, 2015 at 05:55:54PM +0200, antoine wrote:
> > This is a patch to the ddk750_power.c file that fixes up five "line over 80
> > characters" warnings and one "return is not a function, parentheses are not
> > required" error found by the checkpatch.pl script.
> That becomes two different change. Please only do one type of change in
> one patch.
Forgot mentioning, please fix the subject also.
regards
sudip
^ permalink raw reply
* Re: [PATCH] sm750fb: coding style fixes lines over 80 chars
From: Vinay Simha @ 2015-07-17 7:28 UTC (permalink / raw)
To: Joe Perches
Cc: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman,
open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
open list:STAGING SUBSYSTEM, open list
In-Reply-To: <1437019057.16262.22.camel@perches.com>
#if 0, but it's also obviously incorrect
It supposed to be some tag #ifdef CONFIG_** .
Could anybody in the loop can reply?
i was just checking on style checks.
Will skip this file , will take up later
On Thu, Jul 16, 2015 at 9:27 AM, Joe Perches <joe@perches.com> wrote:
> On Thu, 2015-07-16 at 00:16 +0530, Vinay Simha BN wrote:
>> scripts/checkpatch.pl kernel coding style fixes of WARNING
>
> Please don't be a checkpatch robot.
>
> Use tools to prompt your brain, but don't ever turn
> your brain off.
>
>> diff --git a/drivers/staging/sm750fb/ddk750_help.h b/drivers/staging/sm750fb/ddk750_help.h
>
>
>> +/* if 718 big endian turned on,be aware that don't use this driver for general
>> + use,only for ppc big-endian */
>> +#warning "big endian on target cpu and enable nature big endian support of 718
>> + capability !"
>
> Yes, this if #if 0, but it's also obviously incorrect
>
> I didn't look at the rest.
>
>
--
Regards,
Vinay Simha.B.N.
^ permalink raw reply
* Re: [PATCH] sm750fb: coding style fixes lines over 80 chars
From: Joe Perches @ 2015-07-17 7:38 UTC (permalink / raw)
To: Vinay Simha BN
Cc: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman,
open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
open list:STAGING SUBSYSTEM, open list
In-Reply-To: <1437118085-8432-1-git-send-email-simhavcs@gmail.com>
On Fri, 2015-07-17 at 12:58 +0530, Vinay Simha BN wrote:
> scripts/checkpatch.pl kernel coding style fixes of WARNING
Please use checkpatch's --strict option until you know
kernel style much better.
> diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
[]
> @@ -259,17 +259,22 @@ unsigned int height, /* width and height of rectangle in pixel value */
> unsigned int rop2);
>
> int hw_imageblit(struct lynx_accel *accel,
> - const char *pSrcbuf, /* pointer to start of source buffer in system memory */
> - u32 srcDelta, /* Pitch value (in bytes) of the source buffer, +ive means top down and -ive mean button up */
> - u32 startBit, /* Mono data can start at any bit in a byte, this value should be 0 to 7 */
> - u32 dBase, /* Address of destination: offset in frame buffer */
> + const char *pSrcbuf, /* pointer to start of source
> + buffer in system memory */
If you change these lines, please use normal kernel comment style.
/*
* comment block
*/
> diff --git a/drivers/staging/sm750fb/sm750_help.h b/drivers/staging/sm750fb/sm750_help.h
[]
> @@ -49,17 +49,23 @@
> /* Field Macros */
> #define FIELD_START(field) (0 ? field)
> #define FIELD_END(field) (1 ? field)
Odd statements.
> -#define FIELD_SIZE(field) (1 + FIELD_END(field) - FIELD_START(field))
> -#define FIELD_MASK(field) (((1 << (FIELD_SIZE(field)-1)) | ((1 << (FIELD_SIZE(field)-1)) - 1)) << FIELD_START(field))
> -#define FIELD_NORMALIZE(reg, field) (((reg) & FIELD_MASK(field)) >> FIELD_START(field))
> -#define FIELD_DENORMALIZE(field, value) (((value) << FIELD_START(field)) & FIELD_MASK(field))
> +#define FIELD_SIZE(field) (1 + FIELD_END(field) - \
> + FIELD_START(field))
> +#define FIELD_MASK(field) (((1 << (FIELD_SIZE(field)-1)) \
> + | ((1 << (FIELD_SIZE(field)-1)) - 1)) \
> + << FIELD_START(field))
> +#define FIELD_NORMALIZE(reg, field) (((reg) & FIELD_MASK(field)) >> \
> + FIELD_START(field))
> +#define FIELD_DENORMALIZE(field, value) (((value) << FIELD_START(field)) & \
> + FIELD_MASK(field))
>
> #define FIELD_INIT(reg, field, value) FIELD_DENORMALIZE(reg ## _ ## field, \
> - reg ## _ ## field ## _ ## value)
> + reg ## _ ## field ## _ ## value)
> #define FIELD_INIT_VAL(reg, field, value) \
> (FIELD_DENORMALIZE(reg ## _ ## field, value))
> #define FIELD_VAL_SET(x, r, f, v) x = x & ~FIELD_MASK(r ## _ ## f) \
> - | FIELD_DENORMALIZE(r ## _ ## f, r ## _ ## f ## _ ## v)
> + | FIELD_DENORMALIZE(r ## _ ## f, \
> + r ## _ ## f ## _ ## v)
I think _none_ of these are actually used so it'd
be better to delete them instead.
^ permalink raw reply
* [PATCH] sm750fb: coding style fixes lines over 80 chars
From: Vinay Simha BN @ 2015-07-17 7:40 UTC (permalink / raw)
Cc: Vinay Simha BN, Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman,
open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
open list:STAGING SUBSYSTEM, open list
In-Reply-To: <1436985972-5431-1-git-send-email-simhavcs@gmail.com>
scripts/checkpatch.pl kernel coding style fixes of WARNING
WARNING: line over 80 characters
Signed-off-by: Vinay Simha BN <simhavcs@gmail.com>
---
drivers/staging/sm750fb/ddk750_display.h | 10 +++++-----
drivers/staging/sm750fb/ddk750_hwi2c.h | 6 ++++--
drivers/staging/sm750fb/ddk750_power.h | 6 +++---
drivers/staging/sm750fb/ddk750_sii164.h | 12 +++++++-----
drivers/staging/sm750fb/sm750.h | 13 ++++++++-----
drivers/staging/sm750fb/sm750_accel.h | 19 ++++++++++++-------
drivers/staging/sm750fb/sm750_help.h | 21 ++++++++++++++-------
drivers/staging/sm750fb/sm750_hw.h | 21 +++++++++++++--------
8 files changed, 66 insertions(+), 42 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_display.h b/drivers/staging/sm750fb/ddk750_display.h
index abccf84..9afa366 100644
--- a/drivers/staging/sm750fb/ddk750_display.h
+++ b/drivers/staging/sm750fb/ddk750_display.h
@@ -110,19 +110,19 @@ typedef enum _disp_output_t {
/* LCD1 show secondary and DSUB show primary */
LCD1_DSUB_DUAL_SWAP = PNL_2_SEC|SEC_TP_ON|PNL_SEQ_ON|
- CRT_2_PRI|PRI_TP_ON|DAC_ON,
+ CRT_2_PRI|PRI_TP_ON|DAC_ON,
LCD1_LCD2_PRI = PNL_2_PRI|PRI_TP_ON|PNL_SEQ_ON|
- CRT_2_PRI|SEC_TP_OFF|DPMS_OFF|DUAL_TFT_ON,
+ CRT_2_PRI|SEC_TP_OFF|DPMS_OFF|DUAL_TFT_ON,
LCD1_LCD2_SEC = PNL_2_SEC|SEC_TP_ON|PNL_SEQ_ON|
- CRT_2_SEC|PRI_TP_OFF|DPMS_OFF|DUAL_TFT_ON,
+ CRT_2_SEC|PRI_TP_OFF|DPMS_OFF|DUAL_TFT_ON,
LCD1_LCD2_DSUB_PRI = PNL_2_PRI|PRI_TP_ON|PNL_SEQ_ON|DAC_ON|
- CRT_2_PRI|SEC_TP_OFF|DPMS_ON|DUAL_TFT_ON,
+ CRT_2_PRI|SEC_TP_OFF|DPMS_ON|DUAL_TFT_ON,
LCD1_LCD2_DSUB_SEC = PNL_2_SEC|SEC_TP_ON|PNL_SEQ_ON|DAC_ON|
- CRT_2_SEC|PRI_TP_OFF|DPMS_ON|DUAL_TFT_ON,
+ CRT_2_SEC|PRI_TP_OFF|DPMS_ON|DUAL_TFT_ON,
}
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.h b/drivers/staging/sm750fb/ddk750_hwi2c.h
index 0b830ba6..3d4e48b 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.h
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.h
@@ -5,6 +5,8 @@
int hwI2CInit(unsigned char busSpeedMode);
void hwI2CClose(void);
-unsigned char hwI2CReadReg(unsigned char deviceAddress, unsigned char registerIndex);
-int hwI2CWriteReg(unsigned char deviceAddress, unsigned char registerIndex, unsigned char data);
+unsigned char hwI2CReadReg(unsigned char deviceAddress,
+ unsigned char registerIndex);
+int hwI2CWriteReg(unsigned char deviceAddress, unsigned char registerIndex,
+ unsigned char data);
#endif
diff --git a/drivers/staging/sm750fb/ddk750_power.h b/drivers/staging/sm750fb/ddk750_power.h
index b7cf6b2..abad4fe 100644
--- a/drivers/staging/sm750fb/ddk750_power.h
+++ b/drivers/staging/sm750fb/ddk750_power.h
@@ -12,9 +12,9 @@ DPMS_t;
#define setDAC(off) \
{ \
POKE32(MISC_CTRL, FIELD_VALUE(PEEK32(MISC_CTRL), \
- MISC_CTRL, \
- DAC_POWER, \
- off)); \
+ MISC_CTRL, \
+ DAC_POWER, \
+ off)); \
}
void ddk750_setDPMS(DPMS_t);
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h b/drivers/staging/sm750fb/ddk750_sii164.h
index f2610c9..a5246bd 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -5,10 +5,11 @@
/* Hot Plug detection mode structure */
typedef enum _sii164_hot_plug_mode_t {
- SII164_HOTPLUG_DISABLE = 0, /* Disable Hot Plug output bit (always high). */
- SII164_HOTPLUG_USE_MDI, /* Use Monitor Detect Interrupt bit. */
- SII164_HOTPLUG_USE_RSEN, /* Use Receiver Sense detect bit. */
- SII164_HOTPLUG_USE_HTPLG /* Use Hot Plug detect bit. */
+ SII164_HOTPLUG_DISABLE = 0, /* Disable Hot Plug output bit
+ (always high) */
+ SII164_HOTPLUG_USE_MDI, /* Use Monitor Detect Interrupt bit. */
+ SII164_HOTPLUG_USE_RSEN, /* Use Receiver Sense detect bit. */
+ SII164_HOTPLUG_USE_HTPLG /* Use Hot Plug detect bit. */
} sii164_hot_plug_mode_t;
@@ -39,7 +40,8 @@ unsigned char sii164IsConnected(void);
unsigned char sii164CheckInterrupt(void);
void sii164ClearInterrupt(void);
#endif
-/* below register definination is used for Silicon Image SiI164 DVI controller chip */
+/* below register definination is used for Silicon Image
+ SiI164 DVI controller chip */
/*
* Vendor ID registers
*/
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 9b101a9..e2bd920 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -32,9 +32,10 @@ struct lynx_accel {
u32, u32, u32, u32,
u32, u32, u32, u32);
- int (*de_imageblit)(struct lynx_accel *, const char *, u32, u32, u32, u32,
- u32, u32, u32, u32,
- u32, u32, u32, u32);
+ int (*de_imageblit)(struct lynx_accel *, const char *,
+ u32, u32, u32, u32,
+ u32, u32, u32, u32,
+ u32, u32, u32, u32);
};
@@ -100,7 +101,8 @@ struct lynxfb_crtc {
int channel;/* which channel this crtc stands for*/
resource_size_t vidmem_size;/* this view's video memory max size */
- /* below attributes belong to info->fix, their value depends on specific adaptor*/
+ /* below attributes belong to info->fix, their value depends on
+ specific adaptor*/
u16 line_pad;/* padding information:0,1,2,4,8,16,... */
u16 xpanstep;
u16 ypanstep;
@@ -113,7 +115,8 @@ struct lynxfb_crtc {
struct fb_fix_screeninfo*);
int (*proc_checkMode)(struct lynxfb_crtc*, struct fb_var_screeninfo*);
- int (*proc_setColReg)(struct lynxfb_crtc*, ushort, ushort, ushort, ushort);
+ int (*proc_setColReg)(struct lynxfb_crtc*, ushort, ushort, ushort,
+ ushort);
void (*clear)(struct lynxfb_crtc*);
/* pan display */
int (*proc_panDisplay)(struct lynxfb_crtc *,
diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
index f252e47..da067a0 100644
--- a/drivers/staging/sm750fb/sm750_accel.h
+++ b/drivers/staging/sm750fb/sm750_accel.h
@@ -26,7 +26,7 @@
#define DE_SOURCE_WRAP_ENABLE 1
#define DE_SOURCE_X_K1 29:16
#define DE_SOURCE_Y_K2 15:0
-#define DE_SOURCE_X_K1_MONO 20:16
+#define DE_SOURCE_X_K1_MONO { 20:16 }
#define DE_DESTINATION 0x4
#define DE_DESTINATION_WRAP 31:31
@@ -259,17 +259,22 @@ unsigned int height, /* width and height of rectangle in pixel value */
unsigned int rop2);
int hw_imageblit(struct lynx_accel *accel,
- const char *pSrcbuf, /* pointer to start of source buffer in system memory */
- u32 srcDelta, /* Pitch value (in bytes) of the source buffer, +ive means top down and -ive mean button up */
- u32 startBit, /* Mono data can start at any bit in a byte, this value should be 0 to 7 */
- u32 dBase, /* Address of destination: offset in frame buffer */
+ const char *pSrcbuf, /* pointer to start of source
+ buffer in system memory */
+ u32 srcDelta, /* Pitch value (in bytes) of the source buffer,
+ +ive means top down and -ive mean button up */
+ u32 startBit, /* Mono data can start at any bit in a byte,
+ this value should be 0 to 7 */
+ u32 dBase, /* Address of destination: offset in frame buffer */
u32 dPitch, /* Pitch value of destination surface in BYTE */
u32 bytePerPixel, /* Color depth of destination surface */
u32 dx,
u32 dy, /* Starting coordinate of destination surface */
u32 width,
u32 height, /* width and height of rectange in pixel value */
- u32 fColor, /* Foreground color (corresponding to a 1 in the monochrome data */
- u32 bColor, /* Background color (corresponding to a 0 in the monochrome data */
+ u32 fColor, /* Foreground color (corresponding to a 1 in the
+ monochrome data */
+ u32 bColor, /* Background color (corresponding to a 0 in the
+ monochrome data */
u32 rop2);
#endif
diff --git a/drivers/staging/sm750fb/sm750_help.h b/drivers/staging/sm750fb/sm750_help.h
index 8dc6bd2..43d700b 100644
--- a/drivers/staging/sm750fb/sm750_help.h
+++ b/drivers/staging/sm750fb/sm750_help.h
@@ -49,17 +49,23 @@
/* Field Macros */
#define FIELD_START(field) (0 ? field)
#define FIELD_END(field) (1 ? field)
-#define FIELD_SIZE(field) (1 + FIELD_END(field) - FIELD_START(field))
-#define FIELD_MASK(field) (((1 << (FIELD_SIZE(field)-1)) | ((1 << (FIELD_SIZE(field)-1)) - 1)) << FIELD_START(field))
-#define FIELD_NORMALIZE(reg, field) (((reg) & FIELD_MASK(field)) >> FIELD_START(field))
-#define FIELD_DENORMALIZE(field, value) (((value) << FIELD_START(field)) & FIELD_MASK(field))
+#define FIELD_SIZE(field) (1 + FIELD_END(field) - \
+ FIELD_START(field))
+#define FIELD_MASK(field) (((1 << (FIELD_SIZE(field)-1)) \
+ | ((1 << (FIELD_SIZE(field)-1)) - 1)) \
+ << FIELD_START(field))
+#define FIELD_NORMALIZE(reg, field) (((reg) & FIELD_MASK(field)) >> \
+ FIELD_START(field))
+#define FIELD_DENORMALIZE(field, value) (((value) << FIELD_START(field)) & \
+ FIELD_MASK(field))
#define FIELD_INIT(reg, field, value) FIELD_DENORMALIZE(reg ## _ ## field, \
- reg ## _ ## field ## _ ## value)
+ reg ## _ ## field ## _ ## value)
#define FIELD_INIT_VAL(reg, field, value) \
(FIELD_DENORMALIZE(reg ## _ ## field, value))
#define FIELD_VAL_SET(x, r, f, v) x = x & ~FIELD_MASK(r ## _ ## f) \
- | FIELD_DENORMALIZE(r ## _ ## f, r ## _ ## f ## _ ## v)
+ | FIELD_DENORMALIZE(r ## _ ## f, \
+ r ## _ ## f ## _ ## v)
#define RGB(r, g, b) \
( \
@@ -68,7 +74,8 @@
#define RGB16(r, g, b) \
( \
- (unsigned short) ((((r) & 0xF8) << 8) | (((g) & 0xFC) << 3) | (((b) & 0xF8) >> 3)) \
+ (unsigned short) ((((r) & 0xF8) << 8) | (((g) & 0xFC) << 3) | \
+ (((b) & 0xF8) >> 3)) \
)
static inline unsigned int absDiff(unsigned int a, unsigned int b)
diff --git a/drivers/staging/sm750fb/sm750_hw.h b/drivers/staging/sm750fb/sm750_hw.h
index ef0a16f..eceea39 100644
--- a/drivers/staging/sm750fb/sm750_hw.h
+++ b/drivers/staging/sm750fb/sm750_hw.h
@@ -61,13 +61,15 @@ struct sm750_state {
int yLCD;
};
-/* sm750_share stands for a presentation of two frame buffer
- that use one sm750 adaptor, it is similar to the super class of lynx_share
- in C++
- */
+/*
+ sm750_share stands for a presentation of two frame buffer
+ that use one sm750 adaptor, it is similar to the super
+ class of lynx_share in C++
+*/
struct sm750_share {
- /* it's better to put lynx_share struct to the first place of sm750_share */
+ /* it's better to put lynx_share struct to the first place of
+ sm750_share */
struct lynx_share share;
struct sm750_state state;
int hwCursor;
@@ -85,10 +87,13 @@ int hw_sm750_deWait(void);
int hw_sm750le_deWait(void);
resource_size_t hw_sm750_getVMSize(struct lynx_share *);
-int hw_sm750_output_checkMode(struct lynxfb_output*, struct fb_var_screeninfo*);
-int hw_sm750_output_setMode(struct lynxfb_output*, struct fb_var_screeninfo*, struct fb_fix_screeninfo*);
+int hw_sm750_output_checkMode(struct lynxfb_output*,
+ struct fb_var_screeninfo*);
+int hw_sm750_output_setMode(struct lynxfb_output*,
+ struct fb_var_screeninfo*, struct fb_fix_screeninfo*);
int hw_sm750_crtc_checkMode(struct lynxfb_crtc*, struct fb_var_screeninfo*);
-int hw_sm750_crtc_setMode(struct lynxfb_crtc*, struct fb_var_screeninfo*, struct fb_fix_screeninfo*);
+int hw_sm750_crtc_setMode(struct lynxfb_crtc*, struct fb_var_screeninfo*,
+ struct fb_fix_screeninfo*);
int hw_sm750_setColReg(struct lynxfb_crtc*, ushort, ushort, ushort, ushort);
int hw_sm750_setBLANK(struct lynxfb_output*, int);
int hw_sm750le_setBLANK(struct lynxfb_output*, int);
--
2.1.2
^ permalink raw reply related
* [PATCH 1/2] staging: sm750fb: ddk750_power.c: Remove optionnal parentheses.
From: Antoine BLIN @ 2015-07-17 13:04 UTC (permalink / raw)
To: sudipm.mukherjee
Cc: teddy.wang, gregkh, linux-fbdev, devel, linux-kernel,
Antoine BLIN
Fix up "return is not a function, parentheses are not required" error found by
the checkpatch.pl script.
Signed-off-by: Antoine BLIN <antoine.blin@lip6.fr>
---
drivers/staging/sm750fb/ddk750_power.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/sm750fb/ddk750_power.c b/drivers/staging/sm750fb/ddk750_power.c
index c8c51be..3c04447 100644
--- a/drivers/staging/sm750fb/ddk750_power.c
+++ b/drivers/staging/sm750fb/ddk750_power.c
@@ -20,7 +20,7 @@ unsigned int getPowerMode(void)
{
if (getChipType() = SM750LE)
return 0;
- return (FIELD_GET(PEEK32(POWER_MODE_CTRL), POWER_MODE_CTRL, MODE));
+ return FIELD_GET(PEEK32(POWER_MODE_CTRL), POWER_MODE_CTRL, MODE);
}
--
2.4.5
^ permalink raw reply related
* [PATCH 2/2] staging: sm750fb: ddk750_power.c: Split lines over 80 characters.
From: Antoine BLIN @ 2015-07-17 13:04 UTC (permalink / raw)
To: sudipm.mukherjee
Cc: teddy.wang, gregkh, linux-fbdev, devel, linux-kernel,
Antoine BLIN
In-Reply-To: <1437138274-23146-1-git-send-email-antoine.blin@lip6.fr>
Fix up "line over 80 characters" warning found by the checkpatch.pl script.
Signed-off-by: Antoine BLIN <antoine.blin@lip6.fr>
---
drivers/staging/sm750fb/ddk750_power.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_power.c b/drivers/staging/sm750fb/ddk750_power.c
index 3c04447..e580dab 100644
--- a/drivers/staging/sm750fb/ddk750_power.c
+++ b/drivers/staging/sm750fb/ddk750_power.c
@@ -8,7 +8,8 @@ void ddk750_setDPMS(DPMS_t state)
if (getChipType() = SM750LE) {
value = PEEK32(CRT_DISPLAY_CTRL);
- POKE32(CRT_DISPLAY_CTRL, FIELD_VALUE(value, CRT_DISPLAY_CTRL, DPMS, state));
+ POKE32(CRT_DISPLAY_CTRL, FIELD_VALUE(value, CRT_DISPLAY_CTRL,
+ DPMS, state));
} else {
value = PEEK32(SYSTEM_CTRL);
value = FIELD_VALUE(value, SYSTEM_CTRL, DPMS, state);
@@ -39,15 +40,18 @@ void setPowerMode(unsigned int powerMode)
switch (powerMode) {
case POWER_MODE_CTRL_MODE_MODE0:
- control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE, MODE0);
+ control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE,
+ MODE0);
break;
case POWER_MODE_CTRL_MODE_MODE1:
- control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE, MODE1);
+ control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE,
+ MODE1);
break;
case POWER_MODE_CTRL_MODE_SLEEP:
- control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE, SLEEP);
+ control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE,
+ SLEEP);
break;
default:
@@ -138,8 +142,9 @@ void enableZVPort(unsigned int enable)
gate = FIELD_SET(gate, CURRENT_GATE, I2C, ON);
#endif
} else {
- /* Disable ZV Port Gate. There is no way to know whether the GPIO pins are being used
- or not. Therefore, do not disable the GPIO gate. */
+ /* Disable ZV Port Gate. There is no way to know whether the
+ GPIO pins are being used or not. Therefore, do not disable the
+ GPIO gate. */
gate = FIELD_SET(gate, CURRENT_GATE, ZVPORT, OFF);
}
--
2.4.5
^ permalink raw reply related
* [PATCH 1/3] staging: sm7xxfb: move sm712fb out of staging
From: Sudip Mukherjee @ 2015-07-17 13:33 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Jonathan Corbet,
Greg Kroah-Hartman
Cc: linux-kernel, linux-fbdev, linux-doc, devel, Sudip Mukherjee
Now since all cleanups are done and the code is ready to be merged lets
move it out of staging into fbdev location.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/staging/Kconfig | 2 --
drivers/staging/Makefile | 1 -
drivers/staging/sm7xxfb/Kconfig | 13 -------------
drivers/staging/sm7xxfb/Makefile | 1 -
drivers/staging/sm7xxfb/TODO | 12 ------------
drivers/video/fbdev/Kconfig | 14 ++++++++++++++
drivers/video/fbdev/Makefile | 1 +
drivers/{staging/sm7xxfb/sm7xx.h => video/fbdev/sm712.h} | 0
.../{staging/sm7xxfb/sm7xxfb.c => video/fbdev/sm712fb.c} | 2 +-
9 files changed, 16 insertions(+), 30 deletions(-)
delete mode 100644 drivers/staging/sm7xxfb/Kconfig
delete mode 100644 drivers/staging/sm7xxfb/Makefile
delete mode 100644 drivers/staging/sm7xxfb/TODO
rename drivers/{staging/sm7xxfb/sm7xx.h => video/fbdev/sm712.h} (100%)
rename drivers/{staging/sm7xxfb/sm7xxfb.c => video/fbdev/sm712fb.c} (99%)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 7f6cae5..a969276 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -56,8 +56,6 @@ source "drivers/staging/vt6656/Kconfig"
source "drivers/staging/iio/Kconfig"
-source "drivers/staging/sm7xxfb/Kconfig"
-
source "drivers/staging/sm750fb/Kconfig"
source "drivers/staging/xgifb/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 347f647..2747c82 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -22,7 +22,6 @@ obj-$(CONFIG_VT6655) += vt6655/
obj-$(CONFIG_VT6656) += vt6656/
obj-$(CONFIG_VME_BUS) += vme/
obj-$(CONFIG_IIO) += iio/
-obj-$(CONFIG_FB_SM7XX) += sm7xxfb/
obj-$(CONFIG_FB_SM750) += sm750fb/
obj-$(CONFIG_FB_XGI) += xgifb/
obj-$(CONFIG_USB_EMXX) += emxx_udc/
diff --git a/drivers/staging/sm7xxfb/Kconfig b/drivers/staging/sm7xxfb/Kconfig
deleted file mode 100644
index e2922ae..0000000
--- a/drivers/staging/sm7xxfb/Kconfig
+++ /dev/null
@@ -1,13 +0,0 @@
-config FB_SM7XX
- tristate "Silicon Motion SM7XX framebuffer support"
- depends on FB && PCI
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
- help
- Frame buffer driver for the Silicon Motion SM710, SM712, SM721
- and SM722 chips.
-
- This driver is also available as a module. The module will be
- called sm7xxfb. If you want to compile it as a module, say M
- here and read <file:Documentation/kbuild/modules.txt>.
diff --git a/drivers/staging/sm7xxfb/Makefile b/drivers/staging/sm7xxfb/Makefile
deleted file mode 100644
index 48f471c..0000000
--- a/drivers/staging/sm7xxfb/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_FB_SM7XX) += sm7xxfb.o
diff --git a/drivers/staging/sm7xxfb/TODO b/drivers/staging/sm7xxfb/TODO
deleted file mode 100644
index 7cb0b24..0000000
--- a/drivers/staging/sm7xxfb/TODO
+++ /dev/null
@@ -1,12 +0,0 @@
-TODO:
-- Dual head support
-- 2D acceleration support
-- use kernel coding style
-- refine the code and remove unused code
-- move it to drivers/video/fbdev/sm7xxfb.c
-
-Please send any patches to
- Greg Kroah-Hartman <greg@kroah.com>
- Sudip Mukherjee <sudipm.mukherjee@gmail.com>
- Teddy Wang <teddy.wang@siliconmotion.com>
- Sudip Mukherjee <sudip@vectorindia.org>
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 2d98de5..2307909 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2475,3 +2475,17 @@ config FB_SSD1307
help
This driver implements support for the Solomon SSD1307
OLED controller over I2C.
+
+config FB_SM712
+ tristate "Silicon Motion SM712 framebuffer support"
+ depends on FB && PCI
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ help
+ Frame buffer driver for the Silicon Motion SM710, SM712, SM721
+ and SM722 chips.
+
+ This driver is also available as a module. The module will be
+ called sm712fb. If you want to compile it as a module, say M
+ here and read <file:Documentation/kbuild/modules.txt>.
diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index cecea50..50ed1b4 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -131,6 +131,7 @@ obj-$(CONFIG_FB_JZ4740) += jz4740_fb.o
obj-$(CONFIG_FB_PUV3_UNIGFX) += fb-puv3.o
obj-$(CONFIG_FB_HYPERV) += hyperv_fb.o
obj-$(CONFIG_FB_OPENCORES) += ocfb.o
+obj-$(CONFIG_FB_SM712) += sm712fb.o
# Platform or fallback drivers go here
obj-$(CONFIG_FB_UVESA) += uvesafb.o
diff --git a/drivers/staging/sm7xxfb/sm7xx.h b/drivers/video/fbdev/sm712.h
similarity index 100%
rename from drivers/staging/sm7xxfb/sm7xx.h
rename to drivers/video/fbdev/sm712.h
diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/video/fbdev/sm712fb.c
similarity index 99%
rename from drivers/staging/sm7xxfb/sm7xxfb.c
rename to drivers/video/fbdev/sm712fb.c
index 07c2199..629bfa2 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/video/fbdev/sm712fb.c
@@ -32,7 +32,7 @@
#include <linux/pm.h>
#endif
-#include "sm7xx.h"
+#include "sm712.h"
/*
* Private structure
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/3] Documentation/fb: add documentation for sm712fb
From: Sudip Mukherjee @ 2015-07-17 13:33 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Jonathan Corbet,
Greg Kroah-Hartman
Cc: linux-kernel, linux-fbdev, linux-doc, devel, Sudip Mukherjee
In-Reply-To: <1437139280-7375-1-git-send-email-sudipm.mukherjee@gmail.com>
Create the documentation for SM712. Mention all the supported modes and
how to use.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
Documentation/fb/sm712fb.txt | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/fb/sm712fb.txt
diff --git a/Documentation/fb/sm712fb.txt b/Documentation/fb/sm712fb.txt
new file mode 100644
index 0000000..c388442
--- /dev/null
+++ b/Documentation/fb/sm712fb.txt
@@ -0,0 +1,31 @@
+What is sm712fb?
+========+
+This is a graphics framebuffer driver for Silicon Motion SM712 based processors.
+
+How to use it?
+=======
+
+Switching modes is done using the video=sm712fb:... boot parameter.
+
+If you want, for example, enable a resolution of 1280x1024x24bpp you should
+pass to the kernel this command line: "video=sm712fb:0x31B".
+
+You should not compile-in vesafb.
+
+Currently supported video modes are:
+
+[Graphic modes]
+
+bpp | 640x480 800x600 1024x768 1280x1024
+----+--------------------------------------------
+ 8 | 0x301 0x303 0x305 0x307
+ 16 | 0x311 0x314 0x317 0x31A
+ 24 | 0x312 0x315 0x318 0x31B
+
+Missing Features
+========
+(alias TODO list)
+
+ * 2D acceleratrion
+ * dual-head support
--
1.8.1.2
^ permalink raw reply related
* [PATCH 3/3] MAINTAINERS: update maintainers list
From: Sudip Mukherjee @ 2015-07-17 13:33 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Jonathan Corbet,
Greg Kroah-Hartman
Cc: linux-kernel, linux-fbdev, linux-doc, devel, Sudip Mukherjee
In-Reply-To: <1437139280-7375-1-git-send-email-sudipm.mukherjee@gmail.com>
Now since sm712fb has moved out of staging update the maintainers list
accordingly.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
MAINTAINERS | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8133cef..2c77c30 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9301,6 +9301,15 @@ S: Maintained
F: drivers/media/i2c/ov2659.c
F: include/media/ov2659.h
+SILICON MOTION SM712 FRAME BUFFER DRIVER
+M: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+M: Teddy Wang <teddy.wang@siliconmotion.com>
+M: Sudip Mukherjee <sudip@vectorindia.org>
+L: linux-fbdev@vger.kernel.org
+S: Maintained
+F: drivers/video/fbdev/sm712*
+F: Documentation/fb/sm712fb.txt
+
SIS 190 ETHERNET DRIVER
M: Francois Romieu <romieu@fr.zoreil.com>
L: netdev@vger.kernel.org
@@ -9721,14 +9730,6 @@ L: linux-wireless@vger.kernel.org
S: Maintained
F: drivers/staging/rtl8723au/
-STAGING - SILICON MOTION SM7XX FRAME BUFFER DRIVER
-M: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
-M: Teddy Wang <teddy.wang@siliconmotion.com>
-M: Sudip Mukherjee <sudip@vectorindia.org>
-L: linux-fbdev@vger.kernel.org
-S: Maintained
-F: drivers/staging/sm7xxfb/
-
STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER
M: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
M: Teddy Wang <teddy.wang@siliconmotion.com>
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 1/3] staging: sm7xxfb: move sm712fb out of staging
From: Greg Kroah-Hartman @ 2015-07-17 16:52 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Jonathan Corbet,
devel, linux-fbdev, linux-kernel, linux-doc
In-Reply-To: <1437139280-7375-1-git-send-email-sudipm.mukherjee@gmail.com>
On Fri, Jul 17, 2015 at 06:51:18PM +0530, Sudip Mukherjee wrote:
> Now since all cleanups are done and the code is ready to be merged lets
> move it out of staging into fbdev location.
This is really hard for the fbdev developers to review. Care to just
make up a single patch that adds the driver to the tree in that location
so they can read the code and review it?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
From: Luis R. Rodriguez @ 2015-07-17 20:29 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: mingo, bp, arnd, bhelgaas, luto, akpm, linux-pci, linux-kernel,
tomi.valkeinen, mst, toshi.kani, linux-fbdev, xen-devel, benh
In-Reply-To: <1436406859-1280-1-git-send-email-mcgrof@do-not-panic.com>
On Wed, Jul 08, 2015 at 06:54:11PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> Ingo,
>
> Boris is on vacation, he picked up these patches on his bp#tip-mm tree [0]
> and they have baked there for a while now. That tree receives 0-day
> bot testing, but other than that its not clear what other tests were
> run on these patches. Boris modified the commit logs a bit, and made one
> optimizaiton to bail early on an PCI ioremap call when it should. These
> patches have no modifications from what is on Boris' tree and tip-mm branch.
>
> The 0 day build bot did find issues on Boris' tree but those are related
> to ioremap_uc() (already upstream) and its first use on atyfb (not
> upstream) -- I will be addressing a fix for that ioremap_uc() issue through
> another patch series prior to posting the final set for atyfb which makes
> use of ioremap_uc().
>
> No issues have been found with this series. Benh did note some possible issues
> with expectations with what is done for write-combining for PowerPC [1] but
> the issue is a rather general long standing issue with semantics of ioremap --
> in the case for ioremap_wc() on PowerPC benh notes that writel() will never
> write-combine as it uses too heavy barriers. Benh notes that although
> writel_relaxed() today is identical to writel() this can be changed. There are
> other general semantics issues with ioremap() variant calls -- we seem to have
> all gotten together to discuss all these issues on a thread where Dan Williams
> is proposing to "unify ioremap prototypes and macro aliases" [1], folks
> intersted on these issues or semantic concerns can drop in and chime there.
>
> Let me know if these are OK or if there are any questions.
>
> [0] http://lkml.kernel.org/r/20150625204703.GC4898@pd.tnic
> [1] http://lkml.kernel.org/r/20150707095012.GQ7021@wotan.suse.de
Ingo,
Just a friendly reminder. Let me know if there are any issues or questions.
Luis
^ permalink raw reply
* Re: [PATCH v6 0/4] atyfb: atyfb: address MTRR corner case
From: Luis R. Rodriguez @ 2015-07-17 20:37 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: mingo, bp, tomi.valkeinen, airlied, arnd, dan.j.williams, hch,
luto, hpa, tglx, geert, ralf, hmh, ross.zwisler, akpm, jgross,
benh, mpe, tj, x86, mst, toshi.kani, stefan.bader, syrjala,
ville.syrjala, linux-pci, linux-mm, linux-fbdev, linux-kernel
In-Reply-To: <1436491499-3289-1-git-send-email-mcgrof@do-not-panic.com>
On Thu, Jul 09, 2015 at 06:24:55PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> Ingo,
>
> Boris is on vacation so sending these through you. This v6 addresses one code
> comment update requested by Ville. Boris had picked up these patches on his
> tree and this series had gone through 0-day bot testing. The only issue it
> found was the lack of ioremap_uc() implementation on some architectures which
> have an IOMMU. There are two approaches to this issue, one is to go and define
> ioremap_uc() on all architectures, another is to provide a default for
> ioremap_uc() as architectures catch up. I've gone with the later approach [0],
> and so to ensure things won't build-break this patch series must also go
> through the same tree as the patch-fixes for ioremap_uc() for missing
> ioremap_uc() implementations go through. I intend on following up with
> implementing ioremap_uc() for other architectures but for that I need to get
> feedback from other architecture developers and that will take time.
>
> Tomi, the framebuffer maintainer had already expressed he was OK for this to go
> through you. The driver maintainer, Ville, has been Cc'd on all the series, but
> has only provided feedback for the comment request as I noted above. This
> series addresses the more complex work on the entire series I've been putting
> out and as such I've provided a TL;DR full review of what this series does in
> my previous v5 patch series, that can be looked at for more details if needed
> [1].
>
> This series depends on the patch which I recently posted to address compilation
> issue on architectures missing ioremap_uc() [0]. If that goes through then it
> should be safe to apply this series, otherwise we have to sit and wait until
> all architectures get ioremap_uc() properly defined.
>
> Please let me know if there are any questions.
>
> [0] http://lkml.kernel.org/r/1436488096-3165-1-git-send-email-mcgrof@do-not-panic.com
> [1] http://lkml.kernel.org/r/1435196060-27350-1-git-send-email-mcgrof@do-not-panic.com
Ingo, please let me know if there are any questions or issues with this series.
Luis
^ permalink raw reply
* [PATCH v2 2/3] Documentation/fb: add documentation for sm712fb
From: Sudip Mukherjee @ 2015-07-18 4:20 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Jonathan Corbet,
Greg Kroah-Hartman
Cc: linux-kernel, linux-fbdev, linux-doc, devel, Sudip Mukherjee
In-Reply-To: <1437192539-14150-1-git-send-email-sudipm.mukherjee@gmail.com>
Create the documentation for SM712. Mention all the supported modes and
how to use.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
Documentation/fb/sm712fb.txt | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/fb/sm712fb.txt
diff --git a/Documentation/fb/sm712fb.txt b/Documentation/fb/sm712fb.txt
new file mode 100644
index 0000000..c388442
--- /dev/null
+++ b/Documentation/fb/sm712fb.txt
@@ -0,0 +1,31 @@
+What is sm712fb?
+========+
+This is a graphics framebuffer driver for Silicon Motion SM712 based processors.
+
+How to use it?
+=======
+
+Switching modes is done using the video=sm712fb:... boot parameter.
+
+If you want, for example, enable a resolution of 1280x1024x24bpp you should
+pass to the kernel this command line: "video=sm712fb:0x31B".
+
+You should not compile-in vesafb.
+
+Currently supported video modes are:
+
+[Graphic modes]
+
+bpp | 640x480 800x600 1024x768 1280x1024
+----+--------------------------------------------
+ 8 | 0x301 0x303 0x305 0x307
+ 16 | 0x311 0x314 0x317 0x31A
+ 24 | 0x312 0x315 0x318 0x31B
+
+Missing Features
+========
+(alias TODO list)
+
+ * 2D acceleratrion
+ * dual-head support
--
1.8.1.2
^ permalink raw reply related
* [PATCH v2 3/3] MAINTAINERS: update maintainers list
From: Sudip Mukherjee @ 2015-07-18 4:20 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Jonathan Corbet,
Greg Kroah-Hartman
Cc: linux-kernel, linux-fbdev, linux-doc, devel, Sudip Mukherjee
In-Reply-To: <1437192539-14150-1-git-send-email-sudipm.mukherjee@gmail.com>
Now since sm712fb has moved out of staging update the maintainers list
accordingly.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
MAINTAINERS | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8133cef..2c77c30 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9301,6 +9301,15 @@ S: Maintained
F: drivers/media/i2c/ov2659.c
F: include/media/ov2659.h
+SILICON MOTION SM712 FRAME BUFFER DRIVER
+M: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+M: Teddy Wang <teddy.wang@siliconmotion.com>
+M: Sudip Mukherjee <sudip@vectorindia.org>
+L: linux-fbdev@vger.kernel.org
+S: Maintained
+F: drivers/video/fbdev/sm712*
+F: Documentation/fb/sm712fb.txt
+
SIS 190 ETHERNET DRIVER
M: Francois Romieu <romieu@fr.zoreil.com>
L: netdev@vger.kernel.org
@@ -9721,14 +9730,6 @@ L: linux-wireless@vger.kernel.org
S: Maintained
F: drivers/staging/rtl8723au/
-STAGING - SILICON MOTION SM7XX FRAME BUFFER DRIVER
-M: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
-M: Teddy Wang <teddy.wang@siliconmotion.com>
-M: Sudip Mukherjee <sudip@vectorindia.org>
-L: linux-fbdev@vger.kernel.org
-S: Maintained
-F: drivers/staging/sm7xxfb/
-
STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER
M: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
M: Teddy Wang <teddy.wang@siliconmotion.com>
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 1/3] staging: sm7xxfb: move sm712fb out of staging
From: Sudip Mukherjee @ 2015-07-18 4:51 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Jonathan Corbet,
devel, linux-fbdev, linux-kernel, linux-doc
In-Reply-To: <20150717165235.GA9138@kroah.com>
On Fri, Jul 17, 2015 at 09:52:35AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jul 17, 2015 at 06:51:18PM +0530, Sudip Mukherjee wrote:
> > Now since all cleanups are done and the code is ready to be merged lets
> > move it out of staging into fbdev location.
>
> This is really hard for the fbdev developers to review. Care to just
> make up a single patch that adds the driver to the tree in that location
> so they can read the code and review it?
I think i misunderstood you. I sent the v2 which was generated with git
format-patch. So the part about deleting it from staging is also there.
Did you mean to only send the part which is adding to the fbdev or is v2
ok?
regards
sudip
^ permalink raw reply
* Re: [RFC PATCH 00/15] pwm: add support for atomic update
From: Boris Brezillon @ 2015-07-20 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1435738921-25027-1-git-send-email-boris.brezillon@free-electrons.com>
Hi Thierry,
I'd like to send a new version of this series fixing the problems
reported by Heiko, but I remember you were not happy with the naming
convention I have chosen for the atomic update function.
Could you have a quick look at this series (I'm not asking for a
detailed review) and let me know which things you'd like me to rename.
Best Regards,
Boris
On Wed, 1 Jul 2015 10:21:46 +0200
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> Hello Thierry,
>
> This series adds support for atomic PWM update, or ITO, the capability
> to update all the parameters of a PWM device (enabled/disabled, period,
> duty and polarity) in one go.
>
> This implementation is still experimental, and I may have missed some key
> aspect, so any feedback are welcome.
>
> Also note that I haven't protected the state update with any locking.
> That's because the existing config does not protect against concurrent
> access to a requested PWM device (see the pwm_config implementation).
> I guess the PWM framework assume the user will implement the proper locking
> scheme if it has to concurrently access the device.
>
> The 5 first patches prepare the addition of the pwm_state concept, which
> will be used to allow atomic updates.
> The following patches introduce the pwm_state struct, initial state
> retrieval and atomic update concepts.
>
> Patches 12 and 13 are showing how one can implement the initial state
> retrieval and atomic update features in a PWM driver (in this specific
> case I implemented it in the rockchip driver).
>
> The last 2 patches are making use of those changes to improve the
> pwm-regulator driver (initializing the regulator state based on the
> initial PWM state).
>
> Best Regards,
>
> Boris
>
> Boris Brezillon (15):
> pwm: add the pwm_is_enabled() helper
> pwm: fix pwm_get_period and pwm_get_duty_cycle prototypes
> pwm: add pwm_get_polarity helper function
> pwm: make use of pwm_get_xxx helpers where appropriate
> pwm: introduce default period and polarity concepts
> pwm: define a new pwm_state struct
> pwm: move the enabled/disabled info to pwm_state struct
> backlight: pwm_bl: remove useless call to pwm_set_period
> pwm: declare a default PWM state
> pwm: add the PWM initial state retrieval infra
> pwm: add the core infrastructure to allow atomic update
> pwm: rockchip: add initial state retrieval
> pwm: rockchip: add support for atomic update
> regulator: pwm: implement ->enable(), ->disable() and ->is_enabled
> methods
> regulator: pwm: properly initialize the ->state field
>
> drivers/leds/leds-pwm.c | 2 +-
> drivers/pwm/core.c | 136 ++++++++++++++++++++++++++++++-----
> drivers/pwm/pwm-atmel-tcb.c | 2 +-
> drivers/pwm/pwm-atmel.c | 6 +-
> drivers/pwm/pwm-bcm-kona.c | 7 +-
> drivers/pwm/pwm-ep93xx.c | 4 +-
> drivers/pwm/pwm-imx.c | 5 +-
> drivers/pwm/pwm-mxs.c | 4 +-
> drivers/pwm/pwm-pxa.c | 2 +-
> drivers/pwm/pwm-renesas-tpu.c | 2 +-
> drivers/pwm/pwm-rockchip.c | 122 ++++++++++++++++++++++++-------
> drivers/pwm/pwm-sun4i.c | 3 +-
> drivers/pwm/pwm-tegra.c | 6 +-
> drivers/pwm/pwm-tiecap.c | 10 +--
> drivers/pwm/pwm-tiehrpwm.c | 6 +-
> drivers/pwm/sysfs.c | 13 ++--
> drivers/regulator/pwm-regulator.c | 60 ++++++++++++++--
> drivers/video/backlight/lm3630a_bl.c | 4 +-
> drivers/video/backlight/pwm_bl.c | 6 +-
> drivers/video/fbdev/ssd1307fb.c | 2 +-
> include/linux/pwm.h | 82 ++++++++++++++++++---
> 21 files changed, 380 insertions(+), 104 deletions(-)
>
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
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