* Re: [PATCH] sm750fb: Fix indentation, spacing and switch-case
From: Sudip Mukherjee @ 2015-03-23 12:57 UTC (permalink / raw)
To: Amitoj Kaur Chawla; +Cc: teddy.wang, gregkh, linux-fbdev, devel, linux-kernel
In-Reply-To: <20150320184105.GA19710@amitoj-Inspiron-3542>
On Sat, Mar 21, 2015 at 12:11:05AM +0530, Amitoj Kaur Chawla wrote:
> Fix the spacing problems with correct indentation and correct use of
> braces and spacing in switch-case statements.
same problem with this patch also, it is not applying.
please refresh it against staging-testing.
regards
sudip
>
^ permalink raw reply
* Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset
From: Lorenzo Stoakes @ 2015-03-23 13:02 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Dan Carpenter, devel, linux-fbdev, Teddy Wang, Greg KH,
linux-kernel
In-Reply-To: <20150323125513.GB8151@sudip-PC>
On 23 March 2015 at 12:55, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> and you need to send v3 now :(
> your series is not applying. Please refresh it against staging-testing
Applies to staging-testing for me. Are you sure you're applying the
correct 'RESEND 2' patches?
--
Lorenzo Stoakes
https:/ljs.io
^ permalink raw reply
* Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset
From: Lorenzo Stoakes @ 2015-03-23 13:16 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Dan Carpenter, devel, linux-fbdev, Teddy Wang, Greg KH,
linux-kernel
In-Reply-To: <20150323131422.GE8151@sudip-PC>
On 23 March 2015 at 13:14, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> On Mon, Mar 23, 2015 at 01:02:52PM +0000, Lorenzo Stoakes wrote:
>> On 23 March 2015 at 12:55, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>>
>> > and you need to send v3 now :(
>> > your series is not applying. Please refresh it against staging-testing
>>
>> Applies to staging-testing for me. Are you sure you're applying the
>> correct 'RESEND 2' patches?
> i think. if you do git log drivers/staging/sm750fb/
> are you getting the first patch author as
> Ragavendra Nagraj <ragavendra.bn@gmail.com> ?
Yep:-
commit de99befd18c10d8085182a1facbb4b8760b2b6fe
Author: Ragavendra Nagraj <ragavendra.bn@gmail.com>
Date: Wed Mar 18 02:37:42 2015 -0700
staging: sm750fb: Fixed no space and indent warns
I've tried applying resend 2 patches to both linux-next and
staging-testing in Greg's staging.git tree, they apply in both places.
--
Lorenzo Stoakes
https:/ljs.io
^ permalink raw reply
* Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset
From: Lorenzo Stoakes @ 2015-03-23 13:21 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Dan Carpenter, devel, linux-fbdev, Teddy Wang, Greg KH,
linux-kernel
In-Reply-To: <CAA5enKaj78eY9vG=7vGhBb_=EpwV6yyKKMjNCUY7BuJvDDvpgg@mail.gmail.com>
On 23 March 2015 at 13:16, Lorenzo Stoakes <lstoakes@gmail.com> wrote:
> I've tried applying resend 2 patches to both linux-next and
> staging-testing in Greg's staging.git tree, they apply in both places.
Sigh. Checking the emails I actually sent, I seem to *somehow* have
sent old files in this resend :S I really don't know how this
happened. My copies of the patches all apply perfectly correctly, but
these are not the ones I sent.
I'll bump versions using the correct --in-reply-to to fix this. Apologies again!
Best,
--
Lorenzo Stoakes
https:/ljs.io
^ permalink raw reply
* Re: [PATCH 0/13] staging: sm750: reformat sm750.c
From: Sudip Mukherjee @ 2015-03-23 13:23 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150322230718.GA16751@x230-arch.club.entropia.de>
On Mon, Mar 23, 2015 at 02:20:05PM +0300, Dan Carpenter wrote:
> These are going to conflict with Lorenzo's patches.
i just checked and informed Lorenzo that his patchset is not applying
to staging-testing, and this patchset also is not applying. Greg has
already applied patches of Raghavendra and Ricardo Ribalda Delgado.
Michel - please refresh your patchset against staging-testing after
making the changes that Dan has suggested.
regards
sudip
>
> regards,
> dan carpenter
>
^ permalink raw reply
* Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset
From: Lorenzo Stoakes @ 2015-03-23 13:25 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Dan Carpenter, devel, linux-fbdev, Teddy Wang, Greg KH,
linux-kernel
In-Reply-To: <CAA5enKYLYiMHS3ZNX-9=17VB1zp0z8bgVRxOKgCE12KgCBGYfw@mail.gmail.com>
On 23 March 2015 at 13:21, Lorenzo Stoakes <lstoakes@gmail.com> wrote:
> Sigh. Checking the emails I actually sent, I seem to *somehow* have
> sent old files in this resend :S I really don't know how this
> happened. My copies of the patches all apply perfectly correctly, but
> these are not the ones I sent.
And just to add to my embarrassment, this is actually *not* the case,
they DO all apply, gmail mangled the patches. So they seem fine after
all!
Sudip - could you try to carefully grab each of the 5 patches with
[RESEND 2] in the subject to make sure you are applying them
correctly?
Best,
--
Lorenzo Stoakes
https:/ljs.io
^ permalink raw reply
* Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset
From: Sudip Mukherjee @ 2015-03-23 13:26 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Dan Carpenter, devel, linux-fbdev, Teddy Wang, Greg KH,
linux-kernel
In-Reply-To: <CAA5enKbKJm2QeH+rbXB+NKw7+O=eXN-01ifLUZPupJ9BF3q+fQ@mail.gmail.com>
On Mon, Mar 23, 2015 at 01:02:52PM +0000, Lorenzo Stoakes wrote:
> On 23 March 2015 at 12:55, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>
> > and you need to send v3 now :(
> > your series is not applying. Please refresh it against staging-testing
>
> Applies to staging-testing for me. Are you sure you're applying the
> correct 'RESEND 2' patches?
i think. if you do git log drivers/staging/sm750fb/
are you getting the first patch author as
Ragavendra Nagraj <ragavendra.bn@gmail.com> ?
regards
sudip
>
> --
> Lorenzo Stoakes
> https:/ljs.io
^ permalink raw reply
* Re: [PATCH 0/13] staging: sm750: reformat sm750.c
From: tofu @ 2015-03-23 13:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150322230718.GA16751@x230-arch.club.entropia.de>
On 03/23/2015 02:11 PM, Sudip Mukherjee wrote:
> On Mon, Mar 23, 2015 at 02:20:05PM +0300, Dan Carpenter wrote:
>> These are going to conflict with Lorenzo's patches.
>
> i just checked and informed Lorenzo that his patchset is not applying
> to staging-testing, and this patchset also is not applying. Greg has
> already applied patches of Raghavendra and Ricardo Ribalda Delgado.
>
> Michel - please refresh your patchset against staging-testing after
> making the changes that Dan has suggested.
I'll update it tonight and rebase it to staging-testing.
regards
Michel v.C.
>
> regards
> sudip
>
>>
>> regards,
>> dan carpenter
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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 RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset
From: Sudip Mukherjee @ 2015-03-23 13:55 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Dan Carpenter, devel, linux-fbdev, Teddy Wang, Greg KH,
linux-kernel
In-Reply-To: <CAA5enKYeq8id8s+w+AA1e0haZci9ZEXj+3VSPdm_=Uy7vbHOFQ@mail.gmail.com>
On Mon, Mar 23, 2015 at 01:25:37PM +0000, Lorenzo Stoakes wrote:
> On 23 March 2015 at 13:21, Lorenzo Stoakes <lstoakes@gmail.com> wrote:
> > Sigh. Checking the emails I actually sent, I seem to *somehow* have
> > sent old files in this resend :S I really don't know how this
> > happened. My copies of the patches all apply perfectly correctly, but
> > these are not the ones I sent.
>
> And just to add to my embarrassment, this is actually *not* the case,
> they DO all apply, gmail mangled the patches. So they seem fine after
> all!
>
> Sudip - could you try to carefully grab each of the 5 patches with
> [RESEND 2] in the subject to make sure you are applying them
> correctly?
my apologies. they are applying properly. i had them already applied
for testing that hardware change, and again i tried to apply them.
sorry for the confusion. :(
regards
sudip
>
> Best,
>
> --
> Lorenzo Stoakes
> https:/ljs.io
^ permalink raw reply
* Re: [PATCH RESEND 2 1/5] staging: sm750fb: Use memset_io instead of memset
From: Sudip Mukherjee @ 2015-03-23 13:55 UTC (permalink / raw)
To: Lorenzo Stoakes; +Cc: teddy.wang, gregkh, linux-fbdev, devel, linux-kernel
In-Reply-To: <1426864935-29350-1-git-send-email-lstoakes@gmail.com>
On Fri, Mar 20, 2015 at 03:22:11PM +0000, Lorenzo Stoakes wrote:
> This patch takes into account that cursor->vstart, crtc->vScreen and
> share->pvMem are pointers to memory-mapped I/O and thus we should use memset_io
> to make this explicit. In addition, some architectures require special treatment
> of memory-mapped I/O so the previous code could actually break without this
> change.
sorry for the confusion.
tested the whole series on hardware.
Tested-by: Sudip Mukherjee <sudip@vectorindia.org>
sudip
^ permalink raw reply
* Re: [PATCH 0/13] staging: sm750: reformat sm750.c
From: Sudip Mukherjee @ 2015-03-23 14:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150322230718.GA16751@x230-arch.club.entropia.de>
On Mon, Mar 23, 2015 at 02:48:03PM +0100, tofu wrote:
> On 03/23/2015 02:11 PM, Sudip Mukherjee wrote:
> > On Mon, Mar 23, 2015 at 02:20:05PM +0300, Dan Carpenter wrote:
> >> These are going to conflict with Lorenzo's patches.
> >
> > i just checked and informed Lorenzo that his patchset is not applying
> > to staging-testing, and this patchset also is not applying. Greg has
> > already applied patches of Raghavendra and Ricardo Ribalda Delgado.
> >
> > Michel - please refresh your patchset against staging-testing after
> > making the changes that Dan has suggested.
> I'll update it tonight and rebase it to staging-testing.
my apologies. your patchset is applying properly, but it is not
applying if i apply Lorenzo's patches first. And in all probability
Greg will apply that first as that has reached his inbox first.
so better will be if you apply Lorenzo's patches to your tree and
then prepare your patches and just write a small comment in your
patch that your patchset depends on the patchset sent by Lorenzo.
regards
sudip
^ permalink raw reply
* Re: [PATCH v1 05/47] pci: add pci_iomap_wc() variants
From: Bjorn Helgaas @ 2015-03-23 17:20 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, H. Peter Anvin,
jgross, Jan Beulich, Borislav Petkov, Suresh Siddha,
venkatesh.pallipadi, Dave Airlie, linux-kernel@vger.kernel.org,
linux-fbdev, x86@kernel.org, xen-devel@lists.xenproject.org,
Luis R. Rodriguez, Ingo Molnar, Daniel Vetter, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Dave Hansen,
Arnd Bergmann, Michael S. Tsirkin, Stefan Bader,
Konrad Rzeszutek Wilk, Ville Syrjälä, David Vrabel,
Toshi Kani, Roger Pau Monné, xen-devel
In-Reply-To: <1426893517-2511-6-git-send-email-mcgrof@do-not-panic.com>
Hi Luis,
This seems OK to me, but I'm curious about a few things.
On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This allows drivers to take advantage of write-combining
> when possible. Ideally we'd have pci_read_bases() just
> peg an IORESOURCE_WC flag for us
We do set IORESOURCE_PREFETCH. Do you mean something different?
> but where exactly
> video devices memory lie varies *largely* and at times things
> are mixed with MMIO registers, sometimes we can address
> the changes in drivers, other times the change requires
> intrusive changes.
What does a video device address have to do with this? I do see that
if a BAR maps only a frame buffer, the device might be able to mark it
prefetchable, while if the BAR mapped both a frame buffer and some
registers, it might not be able to make it prefetchable. But that
doesn't seem like it depends on the *address*.
pci_iomap_range() already makes a cacheable mapping if
IORESOURCE_CACHEABLE; I'm guessing that you would like it to
automatically use WC if the BAR if IORESOURCE_PREFETCH, e.g.,
if (flags & IORESOURCE_CACHEABLE)
return ioremap(start, len);
if (flags & IORESOURCE_PREFETCH)
return ioremap_wc(start, len);
return ioremap_nocache(start, len);
Is there a reason not to do that?
> Although there is also arch_phys_wc_add() that makes use of
> architecture specific write-combinging alternatives (MTRR on
> x86 when a system does not have PAT) we void polluting
> pci_iomap() space with it and force drivers and subsystems
> that want to use it to be explicit.
>
> There are a few motivations for this:
>
> a) Take advantage of PAT when available
>
> b) Help bury MTRR code away, MTRR is architecture specific and on
> x86 its replaced by PAT
>
> c) Help with the goal of eventually using _PAGE_CACHE_UC over
> _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
> ...
> +void __iomem *pci_iomap_wc_range(struct pci_dev *dev,
> + int bar,
> + unsigned long offset,
> + unsigned long maxlen)
> +{
> + resource_size_t start = pci_resource_start(dev, bar);
> + resource_size_t len = pci_resource_len(dev, bar);
> + unsigned long flags = pci_resource_flags(dev, bar);
> +
> + if (len <= offset || !start)
> + return NULL;
> + len -= offset;
> + start += offset;
> + if (maxlen && len > maxlen)
> + len = maxlen;
> + if (flags & IORESOURCE_IO)
> + return __pci_ioport_map(dev, start, len);
> + if (flags & IORESOURCE_MEM)
Should we log a note in dmesg if the BAR is *not* IORESOURCE_PREFETCH?
I know the driver might know it's safe even if the device didn't mark
the BAR as prefetchable, but it does seem like an easy way for a
driver to shoot itself in the foot.
> + return ioremap_wc(start, len);
> + /* What? */
> + return NULL;
> +}
^ permalink raw reply
* [PATCH 1/2] staging: sm7xxfb: start using module parameters
From: Sudip Mukherjee @ 2015-03-24 4:50 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Sudip Mukherjee, linux-fbdev, devel, linux-kernel
add module parameters so that we can configure X and Y resolutions
and bpp when using this driver as a module.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/staging/sm7xxfb/sm7xxfb.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
index abdb021..6e9b2aa 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -1033,6 +1033,24 @@ static int __init sm712fb_init(void)
module_init(sm712fb_init);
+module_param(mode_option, charp, S_IRUGO);
+
+MODULE_PARM_DESC(mode_option, "\n\t\tOptions:\n"
+ "\t\t0x301 = 640x480-8\n"
+ "\t\t0x303 = 800x600-8\n"
+ "\t\t0x305 = 1024x768-8\n"
+ "\t\t0x307 = 1280x1024-8\n"
+ "\t\t0x311 = 640x480-16\n"
+ "\t\t0x314 = 800x600-16\n"
+ "\t\t0x317 = 1024x768-16\n"
+ "\t\t0x31A = 1280x1024-16\n"
+ "\t\t0x312 = 640x480-24\n"
+ "\t\t0x315 = 800x600-24\n"
+ "\t\t0x318 = 1024x768-24\n"
+ "\t\t0x31B = 1280x1024-24\n"
+ "\t\tUsual example:\n"
+ "\t\tinsmod ./sm7xxfb.ko mode_option=\"0x301\"\n");
+
static void __exit sm712fb_exit(void)
{
pci_unregister_driver(&smtcfb_driver);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/2] staging: sm7xxfb: add MODULE_DEVICE_TABLE
From: Sudip Mukherjee @ 2015-03-24 4:50 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Sudip Mukherjee, linux-fbdev, devel, linux-kernel
In-Reply-To: <1427172609-4318-1-git-send-email-sudipm.mukherjee@gmail.com>
add MODULE_DEVICE_TABLE to support hot-plugging.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/staging/sm7xxfb/sm7xxfb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
index 6e9b2aa..15509a6 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -922,6 +922,8 @@ static const struct pci_device_id smtcfb_pci_table[] = {
{0,}
};
+MODULE_DEVICE_TABLE(pci, smtcfb_pci_table);
+
static void smtcfb_pci_remove(struct pci_dev *pdev)
{
struct smtcfb_info *sfb;
--
1.8.1.2
^ permalink raw reply related
* [PATCH] staging: sm750fb: Fixed C99 comments warnings
From: Ragavendra Nagraj @ 2015-03-24 4:51 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, devel,
linux-kernel
This patch fixes the C99-style "// ..." comments warnings identified by the
checkpath.pl script for the entire ddk750_chip.c file by using the
appropriate C89 "/* ... */" style comments accordingly.
Signed-off-by: Ragavendra Nagraj <ragavendra.bn@gmail.com>
---
drivers/staging/sm750fb/ddk750_chip.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_chip.c b/drivers/staging/sm750fb/ddk750_chip.c
index 02f9326..1fb00a4 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -17,7 +17,7 @@ logical_chip_type_t getChipType(void)
char physicalRev;
logical_chip_type_t chip;
- physicalID = devId750;//either 0x718 or 0x750
+ physicalID = devId750;/*either 0x718 or 0x750*/
physicalRev = revId750;
if (physicalID = 0x718)
@@ -264,7 +264,7 @@ int ddk750_initHw(initchip_param_t * pInitParam)
unsigned int ulReg;
#if 0
- //move the code to map regiter function.
+ /*move the code to map regiter function.*/
if(getChipType() = SM718){
/* turn on big endian bit*/
ulReg = PEEK32(0x74);
@@ -501,7 +501,7 @@ unsigned int calcPllValue(unsigned int request_orig,pll_value_t *pll)
}
}
- //printk("Finally: pll->n[%lu],m[%lu],od[%lu],pod[%lu]\n",pll->N,pll->M,pll->OD,pll->POD);
+ /*printk("Finally: pll->n[%lu],m[%lu],od[%lu],pod[%lu]\n",pll->N,pll->M,pll->OD,pll->POD);*/
return ret;
}
@@ -597,13 +597,13 @@ pll_value_t *pPLL /* Structure to hold the value to be set in PLL */
}
/* Restore input frequency from Khz to hz unit */
-// pPLL->inputFreq *= 1000;
+/* pPLL->inputFreq *= 1000;*/
ulRequestClk *= 1000;
pPLL->inputFreq = DEFAULT_INPUT_CLOCK; /* Default reference clock */
/* Output debug information */
- //DDKDEBUGPRINT((DISPLAY_LEVEL, "calcPllValue: Requested Frequency = %d\n", ulRequestClk));
- //DDKDEBUGPRINT((DISPLAY_LEVEL, "calcPllValue: Input CLK = %dHz, M=%d, N=%d, OD=%d, POD=%d\n", pPLL->inputFreq, pPLL->M, pPLL->N, pPLL->OD, pPLL->POD));
+ /*DDKDEBUGPRINT((DISPLAY_LEVEL, "calcPllValue: Requested Frequency = %d\n", ulRequestClk));*/
+ /*DDKDEBUGPRINT((DISPLAY_LEVEL, "calcPllValue: Input CLK = %dHz, M=%d, N=%d, OD=%d, POD=%d\n", pPLL->inputFreq, pPLL->M, pPLL->N, pPLL->OD, pPLL->POD));*/
/* Return actual frequency that the PLL can set */
ret = calcPLL(pPLL);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] staging: sm750fb: Fixed C99 comments warnings
From: Dan Carpenter @ 2015-03-24 7:57 UTC (permalink / raw)
To: Ragavendra Nagraj
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, devel,
linux-kernel
In-Reply-To: <20150324045154.GA12298@localhost.localdomain>
On Mon, Mar 23, 2015 at 09:51:54PM -0700, Ragavendra Nagraj wrote:
> diff --git a/drivers/staging/sm750fb/ddk750_chip.c b/drivers/staging/sm750fb/ddk750_chip.c
> index 02f9326..1fb00a4 100644
> --- a/drivers/staging/sm750fb/ddk750_chip.c
> +++ b/drivers/staging/sm750fb/ddk750_chip.c
> @@ -17,7 +17,7 @@ logical_chip_type_t getChipType(void)
> char physicalRev;
> logical_chip_type_t chip;
>
> - physicalID = devId750;//either 0x718 or 0x750
> + physicalID = devId750;/*either 0x718 or 0x750*/
This should be:
physicalID = devId750; /* either 0x718 or 0x750 */
> @@ -501,7 +501,7 @@ unsigned int calcPllValue(unsigned int request_orig,pll_value_t *pll)
> }
> }
>
> - //printk("Finally: pll->n[%lu],m[%lu],od[%lu],pod[%lu]\n",pll->N,pll->M,pll->OD,pll->POD);
> + /*printk("Finally: pll->n[%lu],m[%lu],od[%lu],pod[%lu]\n",pll->N,pll->M,pll->OD,pll->POD);*/
Just delete this dead code.
Please redo.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 1/2] staging: sm7xxfb: start using module parameters
From: Greg Kroah-Hartman @ 2015-03-24 9:48 UTC (permalink / raw)
To: Sudip Mukherjee; +Cc: devel, linux-fbdev, linux-kernel
In-Reply-To: <1427172609-4318-1-git-send-email-sudipm.mukherjee@gmail.com>
On Tue, Mar 24, 2015 at 10:20:08AM +0530, Sudip Mukherjee wrote:
> add module parameters so that we can configure X and Y resolutions
> and bpp when using this driver as a module.
>
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> ---
> drivers/staging/sm7xxfb/sm7xxfb.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
> index abdb021..6e9b2aa 100644
> --- a/drivers/staging/sm7xxfb/sm7xxfb.c
> +++ b/drivers/staging/sm7xxfb/sm7xxfb.c
> @@ -1033,6 +1033,24 @@ static int __init sm712fb_init(void)
>
> module_init(sm712fb_init);
>
> +module_param(mode_option, charp, S_IRUGO);
> +
> +MODULE_PARM_DESC(mode_option, "\n\t\tOptions:\n"
> + "\t\t0x301 = 640x480-8\n"
> + "\t\t0x303 = 800x600-8\n"
> + "\t\t0x305 = 1024x768-8\n"
> + "\t\t0x307 = 1280x1024-8\n"
> + "\t\t0x311 = 640x480-16\n"
> + "\t\t0x314 = 800x600-16\n"
> + "\t\t0x317 = 1024x768-16\n"
> + "\t\t0x31A = 1280x1024-16\n"
> + "\t\t0x312 = 640x480-24\n"
> + "\t\t0x315 = 800x600-24\n"
> + "\t\t0x318 = 1024x768-24\n"
> + "\t\t0x31B = 1280x1024-24\n"
> + "\t\tUsual example:\n"
> + "\t\tinsmod ./sm7xxfb.ko mode_option=\"0x301\"\n");
> +
That's funny :)
And how do you handle multiple devices in the system?
:(
Seriously, never use module parameters for device parameters, they are
two different things. The framebuffer core has options for handling
modes, why not use them?
And yes, lots of framebuffer drivers do have crazy module parameters,
but that doesn't mean you have to perpetuate the insanity, please do
things properly here.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] staging: sm7xxfb: start using module parameters
From: Greg Kroah-Hartman @ 2015-03-24 10:40 UTC (permalink / raw)
To: Sudip Mukherjee; +Cc: devel, linux-fbdev, linux-kernel
In-Reply-To: <20150324102835.GA7986@sudip-PC>
On Tue, Mar 24, 2015 at 03:58:35PM +0530, Sudip Mukherjee wrote:
> On Tue, Mar 24, 2015 at 10:48:26AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Mar 24, 2015 at 10:20:08AM +0530, Sudip Mukherjee wrote:
> > > + "\t\t0x31B = 1280x1024-24\n"
> > > + "\t\tUsual example:\n"
> > > + "\t\tinsmod ./sm7xxfb.ko mode_option=\"0x301\"\n");
> > > +
> >
> > That's funny :)
> >
> > And how do you handle multiple devices in the system?
> frankly speaking, never got the idea about multiple devices.
>
> >
> > :(
> >
> > Seriously, never use module parameters for device parameters, they are
> > two different things. The framebuffer core has options for handling
> > modes, why not use them?
> >
> > And yes, lots of framebuffer drivers do have crazy module parameters,
> > but that doesn't mean you have to perpetuate the insanity, please do
> > things properly here.
> i am learning from other framebuffer drivers. i guess i should only
> see at skeletonfb.c and not the others.
> please drop this 1/2 patch, do i need to resend the 2/2 which adds
> the MODULE_DEVICE_TABLE ?
Please do, it's long gone from my queue.
^ permalink raw reply
* Re: [PATCH 1/2] staging: sm7xxfb: start using module parameters
From: Sudip Mukherjee @ 2015-03-24 10:40 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: devel, linux-fbdev, linux-kernel
In-Reply-To: <20150324094826.GB6378@kroah.com>
On Tue, Mar 24, 2015 at 10:48:26AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Mar 24, 2015 at 10:20:08AM +0530, Sudip Mukherjee wrote:
> > + "\t\t0x31B = 1280x1024-24\n"
> > + "\t\tUsual example:\n"
> > + "\t\tinsmod ./sm7xxfb.ko mode_option=\"0x301\"\n");
> > +
>
> That's funny :)
>
> And how do you handle multiple devices in the system?
frankly speaking, never got the idea about multiple devices.
>
> :(
>
> Seriously, never use module parameters for device parameters, they are
> two different things. The framebuffer core has options for handling
> modes, why not use them?
>
> And yes, lots of framebuffer drivers do have crazy module parameters,
> but that doesn't mean you have to perpetuate the insanity, please do
> things properly here.
i am learning from other framebuffer drivers. i guess i should only
see at skeletonfb.c and not the others.
please drop this 1/2 patch, do i need to resend the 2/2 which adds
the MODULE_DEVICE_TABLE ?
regards
sudip
>
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH resend] staging: sm7xxfb: add MODULE_DEVICE_TABLE
From: Sudip Mukherjee @ 2015-03-24 10:52 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-fbdev, devel, linux-kernel, Sudip Mukherjee
add MODULE_DEVICE_TABLE to support hot-plugging.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
resending as discussed with Greg K-H
drivers/staging/sm7xxfb/sm7xxfb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
index abdb021..5b3e614 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -922,6 +922,8 @@ static const struct pci_device_id smtcfb_pci_table[] = {
{0,}
};
+MODULE_DEVICE_TABLE(pci, smtcfb_pci_table);
+
static void smtcfb_pci_remove(struct pci_dev *pdev)
{
struct smtcfb_info *sfb;
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCHv4 04/10] fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
From: Maxime Ripard @ 2015-03-24 15:24 UTC (permalink / raw)
To: Thomas Niederprüm
Cc: plagnioj, tomi.valkeinen, kernel, shawn.guo, robh+dt, linux-fbdev,
linux-kernel
In-Reply-To: <20150320221254.2cc5f502@maestro.intranet>
[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]
On Fri, Mar 20, 2015 at 10:12:54PM +0100, Thomas Niederprüm wrote:
> > > static const struct of_device_id ssd1307fb_of_match[] = {
> > > {
> > > .compatible = "solomon,ssd1306fb-i2c",
> > > - .data = (void *)&ssd1307fb_ssd1306_ops,
> > > + .data = (void *)&ssd1307fb_ssd1306_deviceinfo,
> > > },
> > > {
> > > .compatible = "solomon,ssd1307fb-i2c",
> > > - .data = (void *)&ssd1307fb_ssd1307_ops,
> > > + .data = (void *)&ssd1307fb_ssd1307_deviceinfo,
> >
> > Do we need this ID? Wouldn't it make more sense to pass the pointer to
> > the struct we need to use?
>
> Are you talking about the device_id inside the struct
> ssd1307_deviceinfo?
Yes.
> I need the device_id to serve special needs of the individual
> controllers during initialization. For example the ssd1307 needs to
> set up the pwm in the init code.
Then you can add a bool in the structure to say whether it needs a PWM
or not.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCHv5 00/11] Cleanup and add support for SSD1305
From: Thomas Niederprüm @ 2015-03-24 21:23 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1423261694-5939-1-git-send-email-niederp@physik.uni-kl.de>
Hi,
this patch series is the result of making the ssd1307fb driver work with
a Newhaven OLED display using the Solomon SSD1305 controller. To achieve
this the intialization code for the SSD1306 and the SSD1307 is merged
and based on DT configuration to reflect the various possible wirings
of the SSD130X controller (04/11). Based on these changes it is straight
forward to add support for the SSD1305 controller (06/11).
While working on the driver I realized that it was not possible to
correctly mmap the video memory from userspace since the address handed
to the userspace app is a logical one where it should be a physical one.
Patch 01/10 fixes this. Furthermore the memory reserved by kzalloc is
not page aligned while the address handed to userspace is aligned to the
next page frame. This problem is fixed by using __get_free_pages() in 02/11.
Furthermore a module parameter is added to set the delay for the
deferred io update (07/11). Also the backlight class is implemented to make
the contrast setting available in userspace (10/11).
changes since v1 (thanks to Maxime for the feedback):
- dedicated patch for fixing smem_start address
- remove page reserve upon vmalloc
- remove return value check upon display turn-off at module unload
- use a module parameter refreshrate rather than delaydivider
- allocate fbdefio dynamically
- use sysfs_create_groups to create sysfs entries
- remove contrast, vhcom and dclk properties from DT since they are
not part of hw description. The contrast module parameter was added
to set contrast at load time. vhcom and dclk stays at it's default
values for now.
- add new DT properties to in tree users of ssd130X
- rebased to apply on top of linux-next
changes since v2 (thanks to Maxime again):
- free memory allocated by vmalloc on driver unload
- set default values in the init code to the ones of the existing ssd1307
init code
- added two ACKs (Maxime Ripard)
changes since v3:
- use backlight class rather than dedicated sysfs files to set the
contrast (Thanks to Tomi Valkeinen)
- remove [PATCHv3 08/10] fbdev: ssd1307fb: Add module parameter bitsperpixel
- add new patch to blank the display (unreviewed)
- allocate video memory through __get_free_pages() rather than vmalloc
(Thanks to Geert Uytterhoeven)
- minor rewordings of the commit messages
changes since v4 (thanks to Maxime):
- added two ACKs (Maxime Ripard)
- fixed typo: s/REFRASHRATE/REFRESHRATE
- updated the documentation to make clear the unit of com-offset
- move addition of the module parameter contrast to a separate patch (09/11)
- fix indentation errors
- get rid of device_id in the device_info struct
Thomas Niederprüm (11):
fbdev: ssd1307fb: fix memory address smem_start.
fbdev: ssd1307fb: Allocate page aligned video memory.
of: Add Solomon Systech vendor prefix.
fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
ARM: mxs: fix in tree users of ssd1306
fbdev: ssd1307fb: Add support for SSD1305
fbdev: ssd1307fb: Add a module parameter to set the refresh rate
fbdev: ssd1307fb: Turn off display on driver unload.
fbdev: ssd1307fb: Add module parameter to set the initial contrast
fbdev: ssd1307fb: add backlight controls for setting the contrast
fbdev: ssd1307fb: Add blank mode
.../devicetree/bindings/vendor-prefixes.txt | 1 +
.../devicetree/bindings/video/ssd1307fb.txt | 23 +-
arch/arm/boot/dts/imx28-cfa10036.dts | 3 +
drivers/video/fbdev/Kconfig | 1 +
drivers/video/fbdev/ssd1307fb.c | 310 +++++++++++++++------
5 files changed, 250 insertions(+), 88 deletions(-)
--
2.3.0
^ permalink raw reply
* [PATCHv5 01/11] fbdev: ssd1307fb: fix memory address smem_start.
From: Thomas Niederprüm @ 2015-03-24 21:23 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1427232238-21099-1-git-send-email-niederp@physik.uni-kl.de>
the smem_start pointer of the framebuffer info struct needs to hold the
physical address rather than the logical address. Right now the logical
address returned by kmalloc is stored. This patch converts this address
to a physical address and thus fixes a driver crash on mmaping the
framebuffer memory due to an access to the wrong memory address.
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/video/fbdev/ssd1307fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index f7ed6d9..61e0ce8 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -515,7 +515,7 @@ static int ssd1307fb_probe(struct i2c_client *client,
info->var.blue.offset = 0;
info->screen_base = (u8 __force __iomem *)vmem;
- info->fix.smem_start = (unsigned long)vmem;
+ info->fix.smem_start = __pa(vmem);
info->fix.smem_len = vmem_size;
fb_deferred_io_init(info);
--
2.3.0
^ permalink raw reply related
* [PATCHv5 02/11] fbdev: ssd1307fb: Allocate page aligned video memory.
From: Thomas Niederprüm @ 2015-03-24 21:23 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1427232238-21099-1-git-send-email-niederp@physik.uni-kl.de>
Currently the videomemory is allocated by kmalloc, making it a memory
region that is not necessarily page aligend. This leads to problems
upon mmap call, where the video memory's address gets aligned to the
next page boundary. The result is that the userspace program that issued
the mmap call is not able to access the video memory from the start to
the next page boundary.
This patch changes the allocation of the video memory to use
__get_free_pages() in order to obtain memory that is aligned
to page boundaries.
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/video/fbdev/ssd1307fb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 61e0ce8..8d34c56 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -489,7 +489,8 @@ static int ssd1307fb_probe(struct i2c_client *client,
vmem_size = par->width * par->height / 8;
- vmem = devm_kzalloc(&client->dev, vmem_size, GFP_KERNEL);
+ vmem = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
+ get_order(vmem_size));
if (!vmem) {
dev_err(&client->dev, "Couldn't allocate graphical memory.\n");
ret = -ENOMEM;
@@ -573,6 +574,7 @@ static int ssd1307fb_remove(struct i2c_client *client)
if (par->ops->remove)
par->ops->remove(par);
fb_deferred_io_cleanup(info);
+ __free_pages(__va(info->fix.smem_start), get_order(info->fix.smem_len));
framebuffer_release(info);
return 0;
--
2.3.0
^ permalink raw reply related
* [PATCHv5 03/11] of: Add Solomon Systech vendor prefix.
From: Thomas Niederprüm @ 2015-03-24 21:23 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1427232238-21099-1-git-send-email-niederp@physik.uni-kl.de>
This patch adds the solomon prefix for Solomon Systech Limited.
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d3f4809..933c8f5 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -169,6 +169,7 @@ sitronix Sitronix Technology Corporation
smsc Standard Microsystems Corporation
snps Synopsys, Inc.
solidrun SolidRun
+solomon Solomon Systech Limited
sony Sony Corporation
spansion Spansion Inc.
sprd Spreadtrum Communications Inc.
--
2.3.0
^ 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