* Re: [PATCH 1/1] backlight: lm3630a_bl: Fix incorrect variable type
From: Jingoo Han @ 2013-09-27 0:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1380196776-27909-1-git-send-email-sachin.kamat@linaro.org>
On Thursday, September 26, 2013 9:00 PM, Sachin Kamat wrote:
>
> 'lm3630a_read' returns a negative error code upon failure. This
> will never get detected by unsigned 'rval'. Make it signed.
Hi Sachin Kamat,
The same patch was already sent by Dan Carpenter two days ago.
Also, it was merged to mm tree by Andrew Morton with my Acked-by.
Thank you for caring. :-)
Best regards,
Jingoo Han
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Daniel Jeong <gshark.jeong@gmail.com>
> ---
> drivers/video/backlight/lm3630a_bl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c
> index c63f918..65392f9 100644
> --- a/drivers/video/backlight/lm3630a_bl.c
> +++ b/drivers/video/backlight/lm3630a_bl.c
> @@ -105,7 +105,7 @@ static int lm3630a_chip_init(struct lm3630a_chip *pchip)
> /* interrupt handling */
> static void lm3630a_delayed_func(struct work_struct *work)
> {
> - unsigned int rval;
> + int rval;
> struct lm3630a_chip *pchip;
>
> pchip = container_of(work, struct lm3630a_chip, work.work);
> --
> 1.7.9.5
^ permalink raw reply
* Re: [PATCH 31/51] DMA-API: media: omap3isp: use dma_coerce_mask_and_coherent()
From: Laurent Pinchart @ 2013-09-27 1:56 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Solarflare linux maintainers,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b,
Mauro Carvalho Chehab
In-Reply-To: <E1VMmCg-0007j1-Pi-eh5Bv4kxaXIANfyc6IWni62ZND6+EDdj@public.gmane.org>
Hi Russell,
Thank you for the patch.
On Thursday 19 September 2013 22:56:02 Russell King wrote:
> The code sequence:
> isp->raw_dmamask = DMA_BIT_MASK(32);
> isp->dev->dma_mask = &isp->raw_dmamask;
> isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> bypasses the architectures check on the DMA mask. It can be replaced
> with dma_coerce_mask_and_coherent(), avoiding the direct initialization
> of this mask.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/media/platform/omap3isp/isp.c | 6 +++---
> drivers/media/platform/omap3isp/isp.h | 3 ---
> 2 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index df3a0ec..1c36080 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -2182,9 +2182,9 @@ static int isp_probe(struct platform_device *pdev)
> isp->pdata = pdata;
> isp->ref_count = 0;
>
> - isp->raw_dmamask = DMA_BIT_MASK(32);
> - isp->dev->dma_mask = &isp->raw_dmamask;
> - isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> + ret = dma_coerce_mask_and_coherent(isp->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
>
> platform_set_drvdata(pdev, isp);
>
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index cd3eff4..ce65d3a 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -152,7 +152,6 @@ struct isp_xclk {
> * @mmio_base_phys: Array with physical L4 bus addresses for ISP register
> * regions.
> * @mmio_size: Array with ISP register regions size in bytes.
> - * @raw_dmamask: Raw DMA mask
> * @stat_lock: Spinlock for handling statistics
> * @isp_mutex: Mutex for serializing requests to ISP.
> * @crashed: Bitmask of crashed entities (indexed by entity ID)
> @@ -190,8 +189,6 @@ struct isp_device {
> unsigned long mmio_base_phys[OMAP3_ISP_IOMEM_LAST];
> resource_size_t mmio_size[OMAP3_ISP_IOMEM_LAST];
>
> - u64 raw_dmamask;
> -
> /* ISP Obj */
> spinlock_t stat_lock; /* common lock for statistic drivers */
> struct mutex isp_mutex; /* For handling ref_count field */
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2] pwm-backlight: allow for non-increasing brightness levels
From: Jingoo Han @ 2013-09-27 3:19 UTC (permalink / raw)
To: 'Thierry Reding', 'Tomi Valkeinen'
Cc: 'Mike Dunn', 'Richard Purdie',
'Jean-Christophe Plagniol-Villard',
'Grant Likely', 'Rob Herring',
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, 'Robert Jarzmik',
'Marek Vasut', 'Jingoo Han'
In-Reply-To: <20130926125953.GB2141@ulmo>
On Thursday, September 26, 2013 10:00 PM, Thierry Reding wrote:
> On Thu, Sep 26, 2013 at 03:08:22PM +0300, Tomi Valkeinen wrote:
> > On 26/09/13 14:51, Thierry Reding wrote:
> > > On Thu, Sep 26, 2013 at 01:03:06PM +0300, Tomi Valkeinen wrote:
> > > [...]
> > >> But if you and Thierry think this version is good, I'll take it.
> > >
> > > That sounds like you want to take it through the fbdev tree. Jingoo is
> > > listed (along with Richard, but he hasn't been responsive to email for
> > > years) as maintainer for the backlight subsystem. Furthermore back at
> >
> > Ah, so they are. I just thought it falls under fbdev, as it's under
> > drivers/video/ =).
> >
> > I don't have any particular "want" to take it through fbdev tree. But I
> > can take it.
> >
> > > the time when I began working on the PWM subsystem, the backlight sub-
> > > system was pretty much orphaned, and pwm-backlight was by far the
> > > biggest user of the PWM subsystem. I adopted the driver at the time
> > > because it needed to be updated for PWM subsystem changes.
> > >
> > > What's the plan going forward? Given the coupling between the PWM
> > > subsystem and the pwm-backlight driver it might be useful to keep
> > > maintaining it as part of the PWM subsystem. On the other hand, there's
> > > some coupling between the driver and the backlight subsystem too.
> >
> > And backlight is coupled with fbdev... Which is something I don't like.
> >
> > > I have a couple of patches queued up for 3.13 that rework parts of the
> > > driver, so it'd be good to know how you guys want to handle this.
> >
> > Well. I'm happy if somebody wants to maintain the backlight side. In
> > fact, I'd be happy if somebody would start restructuring it totally,
> > it's rather messy. The link with fbdev should be removed, and some
> > backlight drivers are actually panel drivers. However, perhaps Common
> > Display Framework is required until it can be fully cleaned.
> >
> > So... For the time being, I'm fine with merging pwm-backlight via any
> > tree that works best. I'm presuming here that backlight framework and
> > fbdev (for the parts that are relevant for backlight) are not really
> > being changed, so there shouldn't be conflicts.
>
> In that case I'll just take it through the PWM tree as I've done for the
> past year. I have some other changes planned for the PWM framework for
> the near future that'll create dependencies between the PWM tree and the
> pwm-backlight driver, so keeping them in one tree will make it easier to
> merge them.
Yes, I think so.
I want you to take the patches for pwm-backlight through the PWM tree,
as you have done.
>
> Longer term it probably makes sense, as you say, for someone to take
> over the backlight subsystem completely and give it the love it could
> really use. If Jingoo can do that, it'd be great. Perhaps it'd be a good
> idea to remove Richard as maintainer since he's obviously no longer
> responding to emails. Keeping him Cc'ed on all patches is just
> pointless.
OK, I will send the patch to remove Richard as maintainer.
I will make a git tree and mailing-list for the backlight subsystem later.
However, I am not certain when it will be done. :-(
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH 1/1] backlight: lm3630a_bl: Fix incorrect variable type
From: Sachin Kamat @ 2013-09-27 3:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1380196776-27909-1-git-send-email-sachin.kamat@linaro.org>
On 27 September 2013 05:44, Jingoo Han <jg1.han@samsung.com> wrote:
> On Thursday, September 26, 2013 9:00 PM, Sachin Kamat wrote:
>
> The same patch was already sent by Dan Carpenter two days ago.
> Also, it was merged to mm tree by Andrew Morton with my Acked-by.
> Thank you for caring. :-)
Sounds great, Thanks for letting me know.
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [PATCH v2] pwm-backlight: allow for non-increasing brightness levels
From: Jingoo Han @ 2013-09-27 3:28 UTC (permalink / raw)
To: 'Tomi Valkeinen', 'Thierry Reding'
Cc: 'Mike Dunn', 'Richard Purdie',
'Jean-Christophe Plagniol-Villard',
'Grant Likely', 'Rob Herring',
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, 'Robert Jarzmik',
'Marek Vasut', 'Laurent Pinchart',
'Jingoo Han'
In-Reply-To: <524423B6.4070609-l0cyMroinI0@public.gmane.org>
On Thursday, September 26, 2013 9:08 PM, Tomi Valkeinen wrote:
> On 26/09/13 14:51, Thierry Reding wrote:
> > On Thu, Sep 26, 2013 at 01:03:06PM +0300, Tomi Valkeinen wrote:
> > [...]
> >> But if you and Thierry think this version is good, I'll take it.
> >
> > That sounds like you want to take it through the fbdev tree. Jingoo is
> > listed (along with Richard, but he hasn't been responsive to email for
> > years) as maintainer for the backlight subsystem. Furthermore back at
>
> Ah, so they are. I just thought it falls under fbdev, as it's under
> drivers/video/ =).
>
> I don't have any particular "want" to take it through fbdev tree. But I
> can take it.
>
> > the time when I began working on the PWM subsystem, the backlight sub-
> > system was pretty much orphaned, and pwm-backlight was by far the
> > biggest user of the PWM subsystem. I adopted the driver at the time
> > because it needed to be updated for PWM subsystem changes.
> >
> > What's the plan going forward? Given the coupling between the PWM
> > subsystem and the pwm-backlight driver it might be useful to keep
> > maintaining it as part of the PWM subsystem. On the other hand, there's
> > some coupling between the driver and the backlight subsystem too.
>
> And backlight is coupled with fbdev... Which is something I don't like.
+cc Laurent Pinchart,
Yes, right.
The backlight should be de-coupled with fbdev.
I remember that Laurent Pinchart was doing this patch.
Laurent Pinchart,
Would you let us know your plan about this? :-)
>
> > I have a couple of patches queued up for 3.13 that rework parts of the
> > driver, so it'd be good to know how you guys want to handle this.
>
> Well. I'm happy if somebody wants to maintain the backlight side. In
> fact, I'd be happy if somebody would start restructuring it totally,
> it's rather messy. The link with fbdev should be removed, and some
> backlight drivers are actually panel drivers. However, perhaps Common
> Display Framework is required until it can be fully cleaned.
I think that some backlight drivers can be moved to 'Common Display Framework',
after 'Common Display Framework' is merged.
But, I am not sure, when it will be completed.
Best regards,
Jingoo Han
>
> So... For the time being, I'm fine with merging pwm-backlight via any
> tree that works best. I'm presuming here that backlight framework and
> fbdev (for the parts that are relevant for backlight) are not really
> being changed, so there shouldn't be conflicts.
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH] video: mxsfb: Add missing break
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-09-27 3:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201309261504.45088.marex@denx.de>
On 15:04 Thu 26 Sep , Marek Vasut wrote:
> Hi Tomi,
>
> > On 26/09/13 14:13, Marek Vasut wrote:
> > > Add missing break into the restore function.
> > >
> > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > Cc: Fabio Estevam <fabio.estevam@freescale.com>
> > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > ---
> > >
> > > drivers/video/mxsfb.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> > > index d250ed0..27197a8 100644
> > > --- a/drivers/video/mxsfb.c
> > > +++ b/drivers/video/mxsfb.c
> > > @@ -620,6 +620,7 @@ static int mxsfb_restore_mode(struct mxsfb_info
> > > *host)
> > >
> > > break;
> > >
> > > case 3:
> > > bits_per_pixel = 32;
> > >
> > > + break;
> > >
> > > case 1:
> > >
> > > default:
> > > return -EINVAL;
> >
> > Thanks, queued for 3.12 fixes.
>
> Can you please also queue this for stable 3.10? It's broken there too.
this you have to do it by yourself by cc stable
Greg will take it not us
Best Regards,
J.
>
> Thanks!
>
> Best regards,
> Marek Vasut
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" 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] MAINTAINERS: remove Richard Purdie as backlight maintainer
From: Jingoo Han @ 2013-09-27 3:59 UTC (permalink / raw)
To: 'Andrew Morton'
Cc: linux-kernel, linux-fbdev, 'Richard Purdie',
'Jingoo Han', 'Thierry Reding',
'Tomi Valkeinen', 'Laurent Pinchart',
'Michael Hennerich', 'Milo Kim',
'Daniel Jeong'
Remove Richard Purdie as backlight subsystem maintainer, since he
is not responding for a few years.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 146ade4..398819c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1645,7 +1645,6 @@ S: Maintained
F: drivers/net/wireless/b43legacy/
BACKLIGHT CLASS/SUBSYSTEM
-M: Richard Purdie <rpurdie@rpsys.net>
M: Jingoo Han <jg1.han@samsung.com>
S: Maintained
F: drivers/video/backlight/
--
1.7.10.4
^ permalink raw reply related
* RE: [PATCH v3 0/5] ARM: vf610: Add DCU framebuffer driver for Vybrid VF610 platform
From: Wang Huan-B18965 @ 2013-09-27 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <523C1DAB.60808@ti.com>
PiA+PiBPbiAwMy8wOS8xMyAxMToyMSwgV2FuZyBIdWFuLUIxODk2NSB3cm90ZToNCj4gPj4+IEhp
LCBKZWFuLUNocmlzdG9waGUsIFRvbWksDQo+ID4+Pg0KPiA+Pj4gQ291bGQgeW91IHBsZWFzZSBo
ZWxwIHRvIHJldmlldyB0aGVzZSBwYXRjaGVzPyBUaGFua3MhDQo+ID4+DQo+ID4+IFRoZXJlIHNl
ZW1lZCB0byBiZSBzb21lIHN0cm9uZyBvcGluaW9ucyB0aGF0IHRoZXJlIHNob3VsZCBiZSBhIGRy
bQ0KPiA+PiBkcml2ZXIgZm9yIHRoaXMgaGFyZHdhcmUsIGluc3RlYWQgb2YgYW4gZmIgZHJpdmVy
LiBTbyBhcyB0aGVyZSBzZWVtcw0KPiA+PiB0byBiZSBkaXNhZ3JlZW1lbnRzIGFib3V0IHRoaXMs
IEknbGwgbGVhdmUgdGhpcyBzZXJpZXMgdG8NCj4gPj4gSmVhbi1DaHJpc3RvcGhlLCB3aG8ncyB0
aGUgcHJpbWFyeSBtYWludGFpbmVyLg0KPiA+IFtBbGlzb24gV2FuZ10NCj4gPg0KPiA+IFRoYW5r
cyBmb3IgVG9taSdzIGNvbW1lbnRzLg0KPiA+DQo+ID4gSSBhZ3JlZSB0aGF0IHdlIGNhbiBpbXBs
ZW1lbnQgdGhlIERSTSBkcml2ZXIgZm9yIHRoZSBEQ1UuIEFzIHRoZQ0KPiA+IGJhbmR3aWR0aCBs
aW1pdGF0aW9uLCBJIHN1Z2dlc3Qgd2UgdXNlIHRoZSBmYiBkcml2ZXIgZmlyc3RseS4gT24gdGhl
DQo+ID4gb3RoZXIgaGFuZCwgdGhlIGZiIGRyaXZlciBjYW4gbWVldCB0aGUgYXBwbGljYXRpb24g
cmVxdWlyZW1lbnQgYmFzZWQNCj4gPiBvbiB0aGlzIFNvQy4gV2UnbGwgdHJ5IHRvIHByb3ZpZGUg
dGhlIERSTSBkcml2ZXIgd2hlbiB0aGlzIElQDQo+ID4gaW50ZWdyYXRlZCBpbnRvIG90aGVyIFNv
Qy4NCj4gDQo+IElmIHlvdSBwbGFuIHRvIG1vdmUgdG8gRFJNIGRyaXZlciBhbnl3YXksIEkgd291
bGQgc3Ryb25nbHkgc3VnZ2VzdA0KPiBtZXJnaW5nIG9ubHkgdGhlIERSTSBkcml2ZXIuIElmIHdl
IG1lcmdlIHRoZSBmYiBkcml2ZXIsIGFuZCBhIGJpdCBsYXRlcg0KPiB0aGUgRFJNIGRyaXZlciBm
b3IgdGhlIHNhbWUgaGFyZHdhcmUsIHdlJ2xsIGhhdmUgdHdvIGRyaXZlcnMgb2Ygd2hpY2gNCj4g
dGhlIG90aGVyIGlzIGFscmVhZHkgZGVwcmVjYXRlZC4NCj4gDQpbQWxpc29uIFdhbmddIFdlIHdp
bGwgbm90IGhhdmUgYmFuZHdpZHRoIGFuZCBkZXZlbG9wIHRoZSBEUk0gZHJpdmVyIGluIHRoZSBu
ZWFyIGZ1dHVyZS4gT24gdGhlIG90aGVyIGhhbmQsIHRoaXMgSVAgaXMgbm90IGludGVncmF0ZWQg
aW50byBvdGhlciBoaWdoLWVuZCBTT0MuIFNvIHRoaXMgZmIgZHJpdmVyIHdpbGwgYmUgdXNlZCBm
b3Igc29tZSBraW5kIG9mIGxvbmcgdGltZSBmb3IgY3VycmVudCBTb0MuIFdlIGNhbiB0cnkgdG8g
cmVtb3ZlIHRoZSBmYiBkcml2ZXIgd2hlbiB3ZSBkZXZlbG9wZWQgdGhlIERSTSBkcml2ZXIgZm9y
IG90aGVyIFNvQy4NCg0KSmVhbi1DaHJpc3RvcGhlLCBEbyB5b3UgaGF2ZSBhbnkgY29tbWVudHM/
IFRoYW5rcy4NCg0KDQpCZXN0IFJlZ2FyZHMsDQpBbGlzb24gV2FuZw0K
^ permalink raw reply
* linux-next: manual merge of the omap_dss2 tree with the fbdev tree
From: Stephen Rothwell @ 2013-09-27 5:49 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-next, linux-kernel, Sachin Kamat,
Jean-Christophe PLAGNIOL-VILLARD, Florian Tobias Schandinat,
linux-fbdev
In-Reply-To: <523FEE23.3010503@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2968 bytes --]
Hi Tomi,
Today's linux-next merge of the omap_dss2 tree got a conflict in
drivers/video/atmel_lcdfb.c between commit 5e8be022fb5b ("video:
atmel_lcdfb: add device tree suport") from the fbdev tree and commit
a36bf1925539 ("video: atmel_lcdfb: Remove redundant dev_set_drvdata")
from the omap_dss2 tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/video/atmel_lcdfb.c
index bf9c5d0,3f7d6dc..0000000
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@@ -1157,30 -934,19 +1157,30 @@@ static int __init atmel_lcdfb_probe(str
}
sinfo = info->par;
+ sinfo->pdev = pdev;
+ sinfo->info = info;
+
+ INIT_LIST_HEAD(&info->modelist);
- if (dev_get_platdata(dev)) {
- pdata_sinfo = dev_get_platdata(dev);
- sinfo->default_bpp = pdata_sinfo->default_bpp;
- sinfo->default_dmacon = pdata_sinfo->default_dmacon;
- sinfo->default_lcdcon2 = pdata_sinfo->default_lcdcon2;
- sinfo->default_monspecs = pdata_sinfo->default_monspecs;
- sinfo->atmel_lcdfb_power_control = pdata_sinfo->atmel_lcdfb_power_control;
- sinfo->guard_time = pdata_sinfo->guard_time;
- sinfo->smem_len = pdata_sinfo->smem_len;
- sinfo->lcdcon_is_backlight = pdata_sinfo->lcdcon_is_backlight;
- sinfo->lcdcon_pol_negative = pdata_sinfo->lcdcon_pol_negative;
- sinfo->lcd_wiring_mode = pdata_sinfo->lcd_wiring_mode;
+ if (pdev->dev.of_node) {
+ ret = atmel_lcdfb_of_init(sinfo);
+ if (ret)
+ goto free_info;
- } else if (dev->platform_data) {
++ } else if (dev_get_platdata(dev)) {
+ struct fb_monspecs *monspecs;
+ int i;
+
- pdata = dev->platform_data;
++ pdata = dev_get_platdata(dev);
+ monspecs = pdata->default_monspecs;
+ sinfo->pdata = *pdata;
+
+ for (i = 0; i < monspecs->modedb_len; i++)
+ fb_add_videomode(&monspecs->modedb[i], &info->modelist);
+
+ sinfo->config = atmel_lcdfb_get_config(pdev);
+
+ info->var.bits_per_pixel = pdata->default_bpp ? pdata->default_bpp : 16;
+ memcpy(&info->monspecs, pdata->default_monspecs, sizeof(info->monspecs));
} else {
dev_err(dev, "cannot get default configuration\n");
goto free_info;
@@@ -1305,11 -1089,16 +1305,11 @@@
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(dev, "failed to register framebuffer device: %d\n", ret);
- goto reset_drvdata;
+ goto free_cmap;
}
- /* add selected videomode to modelist */
- fb_var_to_videomode(&fbmode, &info->var);
- fb_add_videomode(&fbmode, &info->modelist);
-
/* Power up the LCDC screen */
- if (sinfo->atmel_lcdfb_power_control)
- sinfo->atmel_lcdfb_power_control(1);
+ atmel_lcdfb_power_control(sinfo, 1);
dev_info(dev, "fb%d: Atmel LCDC at 0x%08lx (mapped at %p), irq %d\n",
info->node, info->fix.mmio_start, sinfo->mmio, sinfo->irq_base);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v11 2/8] usb: phy: omap-usb2: use the new generic PHY framework
From: Kishon Vijay Abraham I @ 2013-09-27 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130926185151.GA8689@kroah.com>
Hi Greg,
On Friday 27 September 2013 12:21 AM, Greg KH wrote:
> On Wed, Aug 21, 2013 at 11:16:07AM +0530, Kishon Vijay Abraham I wrote:
>> Used the generic PHY framework API to create the PHY. Now the power off and
>> power on are done in omap_usb_power_off and omap_usb_power_on respectively.
>> The omap-usb2 driver is also moved to driver/phy.
>>
>> However using the old USB PHY library cannot be completely removed
>> because OTG is intertwined with PHY and moving to the new framework
>> will break OTG. Once we have a separate OTG state machine, we
>> can get rid of the USB PHY library.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> Acked-by: Felipe Balbi <balbi@ti.com>
>> ---
>> drivers/phy/Kconfig | 12 +++++++++
>> drivers/phy/Makefile | 1 +
>> drivers/{usb => }/phy/phy-omap-usb2.c | 45 ++++++++++++++++++++++++++++++---
>> drivers/usb/phy/Kconfig | 10 --------
>> drivers/usb/phy/Makefile | 1 -
>> 5 files changed, 54 insertions(+), 15 deletions(-)
>> rename drivers/{usb => }/phy/phy-omap-usb2.c (88%)
>
> I tried to apply this to my USB branch, but it fails.
>
> Kishon, you were going to refresh this patch series, right? Please do,
> because as-is, I can't take it.
Just sent.
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH] pwm-backlight: add support for device tree gpio control
From: Tomi Valkeinen @ 2013-09-27 6:55 UTC (permalink / raw)
To: Thierry Reding
Cc: Mike Dunn, Richard Purdie, Jingoo Han,
Jean-Christophe Plagniol-Villard, Grant Likely, Rob Herring,
linux-pwm, linux-fbdev, linux-kernel, devicetree, Robert Jarzmik,
Marek Vasut
In-Reply-To: <20130926125020.GA2141@ulmo>
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
On 26/09/13 15:50, Thierry Reding wrote:
>> I thought the NAK was for the DT parts, not for the sequences as such. I
>> don't remember anyone shooting down the idea of defining power sequences
>> inside a driver.
>
> Yes, but the DT parts were the primary reason why they were written in
> the first place. Without DT we can just use the existing hooks to do the
> sequencing. There is not much to be gained from power sequences.
Board hooks? Those cannot be used with DT boot.
But yes, the power sequences without DT (or platform data) parts cannot
handle with board-specific-things. I still think it'd be a very nice
thing to have inside the drivers. A single driver could more easily
handle bunch of somewhat similar devices, by specifying power sequences
in a table, one sequence for each device.
> There is unfortunately always the next crazy setup that one can think
> of. I personally prefer to support what we have (or at least the
> majority of that) with something generic and tackle the more exotic
> setups later on (or when they appear, as the case may be).
>
> As things stand right now, there's no way to get the simplest panel
> setup to work properly if you use DT. By adding both an enable GPIO and
> a power supply regulator we can at least cover the sane use-cases with
> some sane and pretty simple code.
Sure, no disagreement there.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] fbcon: fix deadlock in fbcon_generic_blank()
From: Tomi Valkeinen @ 2013-09-27 7:15 UTC (permalink / raw)
To: John Tapsell
Cc: Jean-Christophe Plagniol-Villard, Peter Hurley, Dave Airlie,
linux-fbdev, linux-kernel
In-Reply-To: <CAHQ6N+q13YeM60S_QfRF8Bh+Vc_7yHhCMSABQ=GOtOe5V0EXow@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
Hi,
On 18/09/13 01:29, John Tapsell wrote:
> Do not lock fb_info when calling sending the FB_EVENT_CONBLANK
> event.
>
> In fbmem.c, the semantics are that we acquire the lock_fb_info first,
> and then console_lock. However when fbcon.c fbcon_generic_blank() is
> called, the console lock could already be held. Locking fb_info can
> thus cause a deadlock.
So has this happened for you? Or is it just theoretical?
> fbmem.c sends the FB_EVENT_BLANK without locking lock_fb_info first, so
> this change introduces similar behaviour.
I don't think this is true. FB_EVENT_BLANK is sent in fb_blank(). That
one is called when FBIOBLANK ioctl is called, and it does lock_fb_info().
I'm not familiar with the console code, but removing a lock makes me
feel rather uneasy... But looking at the code, I can also see that
console_lock could already be held, so something here definitely looks
broken.
The only place using FB_EVENT_CONBLANK seems to be backlight, and if I'm
not mistaken, it has its own lock, and doesn't depend on the fb_info
being locked.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/51] DMA mask changes
From: Russell King - ARM Linux @ 2013-09-27 8:27 UTC (permalink / raw)
To: Rafał Miłecki
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel@driverdev.osuosl.org, linux-samsung-soc,
Linux SCSI List, e1000-devel, b43-dev, linux-media, devicetree,
dri-devel, linux-tegra, linux-omap,
linux-arm-kernel@lists.infradead.org,
Solarflare linux maintainers, Network Development, linux-usb,
linux-wireless@vger.kernel.org, linux-crypto, uclinux-dist-devel
In-Reply-To: <CACna6rxkpYzdD8_Jfi22vA2suUa3k-JM65_gCySQpp4crVCoPg@mail.gmail.com>
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote:
> 2013/9/19 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > This email is only being sent to the mailing lists in question, not to
> > anyone personally. The list of individuals is far to great to do that.
> > I'm hoping no mailing lists reject the patches based on the number of
> > recipients.
>
> Huh, I think it was enough to send only 3 patches to the b43-dev@. Like:
> [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
> [PATCH 14/51] DMA-API: net: b43: (...)
> [PATCH 15/51] DMA-API: net: b43legacy: (...)
> ;)
>
> I believe Joe has some nice script for doing it that way. When fixing
> some coding style / formatting, he sends only related patches to the
> given ML.
If I did that, then the mailing lists would not get the first patch,
because almost none of the lists would be referred to by patch 1.
Moreover, people complain when they don't have access to the full
patch series - they assume patches are missing for some reason, and
they ask for the rest of the series.
^ permalink raw reply
* [GIT PULL] fbdev fixes for 3.12
From: Tomi Valkeinen @ 2013-09-27 9:07 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-fbdev, linux-kernel, Jean-Christophe PLAGNIOL-VILLARD
[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]
Hi Linus,
The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-fixes-3.12
for you to fetch changes up to 6d0bb818041a02be682abadb3ba35ff608f7d60a:
video: mxsfb: Add missing break (2013-09-26 15:33:23 +0300)
----------------------------------------------------------------
Small fbdev fixes for various fb drivers
----------------------------------------------------------------
Andrzej Hajda (1):
video: of: display_timing: correct display-timings node finding
Marek Vasut (1):
video: mxsfb: Add missing break
Mark Brown (1):
OMAPDSS: Add missing dependency on backlight for DSI-CM panel drier
Sathya Prakash M R (1):
OMAPDSS: Return right error during connector probe
Tomi Valkeinen (1):
OMAPDSS: DISPC: set irq_safe for runtime PM
Uwe Kleine-König (1):
video: mmp: drop needless devm cleanup
Wei Yongjun (2):
s3fb: fix error return code in s3_pci_probe()
neofb: fix error return code in neofb_probe()
drivers/video/mmp/hw/mmp_ctrl.c | 17 ++---------------
drivers/video/mxsfb.c | 1 +
drivers/video/neofb.c | 4 +++-
drivers/video/of_display_timing.c | 6 +++---
drivers/video/omap2/displays-new/Kconfig | 1 +
drivers/video/omap2/displays-new/connector-analog-tv.c | 2 +-
drivers/video/omap2/displays-new/connector-dvi.c | 2 +-
drivers/video/omap2/displays-new/connector-hdmi.c | 2 +-
drivers/video/omap2/dss/dispc.c | 1 +
drivers/video/s3fb.c | 9 +--------
10 files changed, 15 insertions(+), 30 deletions(-)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Vážení E-mail užívateľa
From: agrobak @ 2013-09-27 9:21 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <49ba66a6c259798998e698b3ed2288d9@nuczv.sk>
--
Vážení E-mail užívateľa;
Prekročili ste 23432 boxy nastaviť svoje
Webová služba / Administrátor, a budete mať problémy pri odosielaní a
prijímať e-maily, kým znova overiť. Musíte aktualizovať
kliknutím na
odkaz nižšie a vyplňte údaje pre overenie vášho účtu
Prosím, kliknite na odkaz nižšie alebo skopírovať vložiť do
e-prehliadač pre overenie Schránky.
http://webmailonlineupdate1.jimdo.com/
Pozor!
Ak tak neurobíte, budú mať obmedzený prístup k e-mailu schránky. Ak
sa
nepodarí aktualizovať svoj účet do troch dní
od aktualizácie
oznámenia,
bude váš účet natrvalo uzavretá.
S pozdravom,
System Administrator ®
^ permalink raw reply
* [PATCH -next] backlight: lm3630: add missing destroy_workqueue() on error in lm3630a_intr_config()
From: Wei Yongjun @ 2013-09-27 9:50 UTC (permalink / raw)
To: linux-fbdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Add the missing destroy_workqueue() before return from
lm3630a_intr_config() in the error handling case.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/video/backlight/lm3630a_bl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c
index c63f918..0e5d8d3 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -154,6 +154,7 @@ static int lm3630a_intr_config(struct lm3630a_chip *pchip)
(pchip->irq, NULL, lm3630a_isr_func,
IRQF_TRIGGER_FALLING | IRQF_ONESHOT, "lm3630a_irq", pchip)) {
dev_err(pchip->dev, "request threaded irq fail\n");
+ destroy_workqueue(pchip->irqthread);
return -ENOMEM;
}
return rval;
^ permalink raw reply related
* Re: [PATCH v4 1/2] video: ARM CLCD: Add DT support
From: Jon Medhurst (Tixy) @ 2013-09-27 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1379686800-27269-1-git-send-email-pawel.moll@arm.com>
On Fri, 2013-09-20 at 15:19 +0100, Pawel Moll wrote:
> This patch adds basic DT bindings for the PL11x CLCD cells
> and make their fbdev driver use them.
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> ---
[...]
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 84b685f..b7d8c23 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -316,6 +316,7 @@ config FB_ARMCLCD
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
To avoid undefined reference to of_get_fb_videomode I needed to also
add:
select FB_MODE_HELPERS
> + select VIDEOMODE_HELPERS if OF
> help
> This framebuffer device driver is for the ARM PrimeCell PL110
> Colour LCD controller. ARM PrimeCells provide the building
[...]
With the config change, for both this patch and patch 2/2
Tested-by: Jon Medhurst <tixy@linaro.org>
(I tested both DT and ATAGs booting on Versatile Express with CA9x4
CoreTile, and DT boot with CA15_A7 a.k.a TC2 :-)
--
Tixy
^ permalink raw reply
* Re: [PATCH] pwm-backlight: add support for device tree gpio control
From: Mike Dunn @ 2013-09-27 13:35 UTC (permalink / raw)
To: Thierry Reding
Cc: Tomi Valkeinen, Richard Purdie, Jingoo Han,
Jean-Christophe Plagniol-Villard, Grant Likely, Rob Herring,
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Jarzmik, Marek Vasut
In-Reply-To: <20130926125020.GA2141@ulmo>
On 09/26/2013 05:50 AM, Thierry Reding wrote:
> On Thu, Sep 26, 2013 at 03:26:13PM +0300, Tomi Valkeinen wrote:
>> On 26/09/13 15:02, Thierry Reding wrote:
>>> On Thu, Sep 26, 2013 at 01:13:18PM +0300, Tomi Valkeinen wrote:
>>>> On 11/09/13 14:40, Mike Dunn wrote:
>>>>> On 09/10/2013 10:21 AM, Thierry Reding wrote:
>>>>
>>>>>> Do you have a real setup that actually needs multiple GPIOs? Usually
>>>>>> such a setup requires some kind of timing or other additional constraint
>>>>>> which can't be represented by this simple binding.
>>>>>>
>>>>>> Looking at the Palm Treo code it seems like the reason why multiple
>>>>>> GPIOs are needed is because one is to enable the backlight, while the
>>>>>> other is in fact used to enable the LCD panel.
>>>>>
>>>>>
>>>>> There are actually four GPIOs involved! (There is an embarrasingly horrible
>>>>> hack in arch/arm/mach-pxa/palmtreo.c that handles the others.) One is almost
>>>>> certainly simply backlight power. The other three are probably LCD related.
>>>>
>>>> When you say "power", do you mean the gpio enables a regulator to feed
>>>> power to the backlight? If so, wouldn't that be a regulator, not gpio,
>>>> from the bl driver's point of view?
>>>>
>>>> Generally speaking, this same problem appears in many places, but for
>>>> some reason especially in display. I'm a bit hesitant in adding "free
>>>> form" gpio/regulator support for drivers, as, as Thierry pointed out,
>>>> there are often timing requirements, or sometimes the gpios are
>>>> inverted, or sometimes the gpio is, in fact, a reset gpio, where you'll
>>>> assert the gpio for a short moment only.
>>>
>>> I sent out another series a few days ago that somewhat obsoletes this
>>> patch. What it does is basically add a single enable GPIO that can be
>>> used to turn the backlight on and off. In a separate patch, support is
>>> added for a power regulator. The combination of both should be able to
>>> cover the majority of use-cases.
>>
>> But Mike's case required 4 GPIOs? Or can that be reduced to one gpio and
>> one regulator?
>
> Well, at least for the backlight it only seemed to involve a single
> GPIO. The other three were probably related to LCD and therefore not
> really suitable for a backlight driver. Traditionally it has been that
> the backlight driver handled these things as well (via the callbacks
> installed by board setup code). While really they should be handled by a
> separate driver (for the LCD).
Yes, this is currently my best guess. This is reverse-engineered and
unfortunately I'm not yet able to accurately describe my particular use-case.
Probably as wacky as anything you can imagine, Thierry :)
The gpio and regulator patches will probably suffice. Thierry, can you please
point me to those patches? I don't see them in your gitorious tree. If they
were posted to linux-pwm, I missed them; sorry.
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH v4 1/2] video: ARM CLCD: Add DT support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-09-27 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1379686800-27269-1-git-send-email-pawel.moll@arm.com>
On 15:19 Fri 20 Sep , Pawel Moll wrote:
> This patch adds basic DT bindings for the PL11x CLCD cells
> and make their fbdev driver use them.
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> ---
> Changes since v3:
> - changed wording and order of interrupt-names and interrupts
> properties documentation
> - changed wording of arm,pl11x,framebuffer-base property
> documentation
> - cleaned up binding documentation indentation
>
> Changes since v2:
> - replaced video-ram phandle with arm,pl11x,framebuffer-base
> - replaced panel-* properties with arm,pl11x,panel-data-pads
> - replaced max-framebuffer-size with max-memory-bandwidth
> - modified clcdfb_of_init_tft_panel() to use the pads
> data and take differences between PL110 and PL110 into
> account
>
> Changes since v1:
> - minor code cleanups as suggested by Sylwester Nawrocki
> .../devicetree/bindings/video/arm,pl11x.txt | 145 +++++++++++
> .../devicetree/bindings/video/arm,pl11x.txt | 146 +++++++++++
> drivers/video/Kconfig | 1 +
> drivers/video/amba-clcd.c | 268 +++++++++++++++++++++
> 3 files changed, 415 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt
>
> diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
> new file mode 100644
> index 0000000..247e120
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
> @@ -0,0 +1,146 @@
> +* ARM PrimeCell Color LCD Controller PL110/PL111
> +
> +See also Documentation/devicetree/bindings/arm/primecell.txt
> +
> +Required properties:
> +
> +- compatible: must be one of:
> + "arm,pl110", "arm,primecell"
> + "arm,pl111", "arm,primecell"
> +
> +- reg: base address and size of the control registers block
> +
> +- interrupt-names: either the single entry "combined" representing a
> + combined interrupt output (CLCDINTR), or the four entries
> + "mbe", "vcomp", "lnbu", "fuf" representing the individual
> + CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts
> +
> +- interrupts: contains an interrupt specifier for each entry in
> + interrupt-names
> +
> +- clocks names: should contain "clcdclk" and "apb_pclk"
> +
> +- clocks: contains phandle and clock specifier pairs for the entries
> + in the clock-names property. See
> + Documentation/devicetree/binding/clock/clock-bindings.txt
> +
> +- arm,pl11x,panel-data-pads: array of 24 cells, each of them describing
> + a function of one of the CLD pads, starting from 0 up to 23;
> + each pad can be described by one of the following values:
> + - 0: reserved (not connected)
> + - 0x100-0x107: color upper STN panel data 0 to 7
> + - 0x110-0x117: color lower STN panel data 0 to 7
> + - 0x200-0x207: mono upper STN panel data 0 to 7
> + - 0x210-0x217: mono lower STN panel data 0 to 7
> + - 0x300-0x307: red component bit 0 to 7 of TFT panel data
> + - 0x310-0x317: green component bit 0 to 7 of TFT panel data
> + - 0x320-0x327: blue component bit 0 to 7 of TFT panel data
> + - 0x330: intensity bit of TFT panel data
sorry Paul for the late comment but those magic are really anoyoing please use
DT macro to make it readable
and maybe you can use phandle to drop the possible duplication across baords
> + Example sets of values for standard panel interfaces:
> + - PL110 single colour STN panel:
> + <0x107 0x106 0x105 0x104 0x103 0x102 0x101 0x100>,
> + <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
> + - PL110 dual colour STN panel:
> + <0x107 0x106 0x105 0x104 0x103 0x102 0x101 0x100>,
> + <0x117 0x116 0x115 0x114 0x113 0x112 0x111 0x110>,
> + <0 0 0 0 0 0 0 0>;
> + - PL110 single mono 4-bit STN panel:
> + <0x203 0x202 0x201 0x200>,
> + <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
> + - PL110 dual mono 4-bit STN panel:
> + <0x203 0x202 0x201 0x200>, <0 0 0 0>,
> + <0x213 0x212 0x211 0x210>,
> + <0 0 0 0 0 0 0 0 0 0 0 0>;
> + - PL110 single mono 8-bit STN panel:
> + <0x207 0x206 0x205 0x204 0x203 0x202 0x201 0x200>,
> + <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
> + - PL110 dual mono 8-bit STN panel:
> + <0x207 0x206 0x205 0x204 0x203 0x202 0x201 0x200>,
> + <0x217 0x216 0x215 0x214 0x213 0x212 0x211 0x210>,
> + <0 0 0 0 0 0 0 0>;
> + - PL110 TFT (1:)5:5:5 panel:
> + <0x330 0x300 0x301 0x302 0x303 0x304>,
> + <0x330 0x310 0x311 0x312 0x313 0x314>,
> + <0x330 0x320 0x321 0x322 0x323 0x324>,
> + <0 0 0 0 0 0>
> + - PL110 and PL111 TFT RGB 888 panel:
> + <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
> + <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
> + <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
> + - PL111 single colour STN panel:
> + <0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107>,
> + <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
> + - PL111 dual colour STN panel:
> + <0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107>,
> + <0x110 0x111 0x112 0x113 0x114 0x115 0x116 0x117>,
> + <0 0 0 0 0 0 0 0>;
> + - PL111 single mono 4-bit STN panel:
> + <0x200 0x201 0x202 0x203>,
> + <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
> + - PL111 dual mono 4-bit STN panel:
> + <0x200 0x201 0x202 0x203>, <0 0 0 0>,
> + <0x210 0x211 0x212 0x213>,
> + <0 0 0 0 0 0 0 0 0 0 0 0>;
> + - PL111 single mono 8-bit STN panel:
> + <0x200 0x201 0x202 0x203 0x204 0x205 0x206 0x207>,
> + <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
> + - PL111 dual mono 8-bit STN panel:
> + <0x200 0x201 0x202 0x203 0x204 0x205 0x206 0x207>,
> + <0x210 0x211 0x212 0x213 0x214 0x215 0x216 0x217>,
> + <0 0 0 0 0 0 0 0>;
> + - PL111 TFT 4:4:4 panel:
> + <0 0 0 0>, <0x300 0x301 0x302 0x303>,
> + <0 0 0 0>, <0x310 0x311 0x312 0x313>,
> + <0 0 0 0>, <0x320 0x321 0x322 0x323>;
> + - PL111 TFT 5:6:5 panel:
> + <0 0 0>, <0x300 0x301 0x302 0x303 0x304>,
> + <0 0>, <0x310 0x311 0x312 0x313 0x314 0x315>,
> + <0 0 0>, <0x320 0x321 0x322 0x323 0x324>;
> + - PL111 TFT (1):5:5:5 panel:
> + <0 0 0>, <0x300 0x301 0x302 0x303 0x304>,
> + <0 0>, <0x330 0x310 0x311 0x312 0x313 0x314>,
> + <0 0 0>, <0x320 0x321 0x322 0x323 0x324>;
> +
> +Optional properties:
> +
> +- arm,pl11x,framebuffer-base: a pair of two values, address and size,
> + defining the framebuffer that must be used; if not present, the
> + framebuffer may be located anywhere in the memory
this should be named ressources not a property for me
> +
> +- max-memory-bandwidth: maximum bandwidth in bytes per second that the
> + cell's memory interface can handle
> +
> +- display-timings: standard display timings sub-node, defining possible
> + video modes of a connected panel; for details see
> + Documentation/devicetree/bindings/video/display-timing.txt
> +
> +Example:
> +
> + clcd@1f0000 {
> + compatible = "arm,pl111", "arm,primecell";
> + reg = <0x1f0000 0x1000>;
> + interrupt-names = "combined";
> + interrupts = <14>;
> + clock-names = "clcdclk", "apb_pclk";
> + clocks = <&v2m_oscclk1>, <&smbclk>;
> +
> + arm,pl11x,panel-data-pads = <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
> + <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
> + <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
> + arm,pl11x,framebuffer-base = <0x18000000 0x00800000>;
> + max-memory-bandwidth = <36864000>; /* bps, 640x480@60 16bpp */
> + display-timings {
> + native-mode = <&v2m_clcd_timing0>;
> + v2m_clcd_timing0: vga {
> + clock-frequency = <25175000>;
> + hactive = <640>;
> + hback-porch = <40>;
> + hfront-porch = <24>;
> + hsync-len = <96>;
> + vactive = <480>;
> + vback-porch = <32>;
> + vfront-porch = <11>;
> + vsync-len = <2>;
> + };
> + };
> + };
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 84b685f..b7d8c23 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -316,6 +316,7 @@ config FB_ARMCLCD
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> + select VIDEOMODE_HELPERS if OF
> help
> This framebuffer device driver is for the ARM PrimeCell PL110
> Colour LCD controller. ARM PrimeCells provide the building
> diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
> index 0a2cce7..03420d1 100644
> --- a/drivers/video/amba-clcd.c
> +++ b/drivers/video/amba-clcd.c
> @@ -25,6 +25,11 @@
> #include <linux/amba/clcd.h>
> #include <linux/clk.h>
> #include <linux/hardirq.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <video/of_display_timing.h>
> +#include <video/of_videomode.h>
>
> #include <asm/sizes.h>
>
> @@ -542,6 +547,266 @@ static int clcdfb_register(struct clcd_fb *fb)
> return ret;
> }
>
> +#ifdef CONFIG_OF
> +
> +#define CLCD_PADS_NUM 24
> +
> +#define CLCD_PAD_BIT(pad) ((pad) & 0xf)
> +#define CLCD_PAD_TYPE(pad) (((pad) >> 8) & 0xf)
> +
> +#define CLCD_PAD_IS_TFT(pad) (CLCD_PAD_TYPE(pad) = 0x3)
> +
> +#define CLCD_PAD_RGB(pad) (((pad) >> 4) & 0xf)
> +#define CLCD_PAD_R 0x0
> +#define CLCD_PAD_G 0x1
> +#define CLCD_PAD_B 0x2
> +
> +static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 *pads)
> +{
> + static struct {
> + unsigned int part;
> + int r0, g0, b0;
> + u32 caps;
> + } panels[] = {
> + { 0x110, 1, 7, 13, CLCD_CAP_5551 },
> + { 0x110, 0, 8, 16, CLCD_CAP_888 },
> + { 0x111, 4, 14, 20, CLCD_CAP_444 },
> + { 0x111, 3, 11, 19, CLCD_CAP_444 | CLCD_CAP_5551 },
> + { 0x111, 3, 10, 19, CLCD_CAP_444 | CLCD_CAP_5551 |
> + CLCD_CAP_565 },
> + { 0x111, 0, 8, 16, CLCD_CAP_444 | CLCD_CAP_5551 |
> + CLCD_CAP_565 | CLCD_CAP_888 },
> + };
> + int r = 0, g = 0, b = 0;
> + int r0 = -1, g0 = -1, b0 = -1;
> + int i;
> +
> + /* Bypass pixel clock divider, data output on the falling edge */
> + fb->panel->tim2 = TIM2_BCD | TIM2_IPC;
> +
> + /* TFT display, vert. comp. interrupt at the start of the back porch */
> + fb->panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
> +
> + fb->panel->caps = 0;
> +
> + /*
> + * Find indices of the first component bits and make sure they
> + * are in correct order
> + */
> + for (i = 0; i < CLCD_PADS_NUM; i++) {
> + int bit;
> +
> + if (!pads[i])
> + continue;
> + switch (CLCD_PAD_RGB(pads[i])) {
> + case CLCD_PAD_R:
> + r0 = r ? r0 : i;
> + bit = r++;
> + break;
> + case CLCD_PAD_G:
> + g0 = g ? g0 : i;
> + bit = g++;
> + break;
> + case CLCD_PAD_B:
> + b0 = b ? b0 : i;
> + bit = b++;
> + break;
> + default:
> + return -EINVAL;
> + }
> + if (bit != CLCD_PAD_BIT(pads[i]) || !CLCD_PAD_IS_TFT(pads[i]))
> + return -EINVAL;
> + }
> +
> + /* Match the setup with known variants */
> + for (i = 0; i < ARRAY_SIZE(panels) && !fb->panel->caps; i++) {
> + if (amba_part(fb->dev) != panels[i].part)
> + continue;
> + if (g0 != panels[i].g0)
> + continue;
> + if (r0 = panels[i].r0 && b0 = panels[i].b0)
> + fb->panel->caps = panels[i].caps & CLCD_CAP_RGB;
> + if (r0 = panels[i].b0 && b0 = panels[i].r0)
> + fb->panel->caps = panels[i].caps & CLCD_CAP_BGR;
> + }
> +
> + return fb->panel->caps ? 0 : -EINVAL;
> +}
> +
> +static int clcdfb_snprintf_mode(char *buf, int size, struct fb_videomode *mode)
> +{
> + return snprintf(buf, size, "%ux%u@%u", mode->xres, mode->yres,
> + mode->refresh);
> +}
> +
> +static int clcdfb_of_init_display(struct clcd_fb *fb)
> +{
> + struct device_node *node = fb->dev->dev.of_node;
> + int err, len;
> + char *mode_name;
> + u32 max_bandwidth;
> + u32 pads[CLCD_PADS_NUM];
> + int i;
> +
> + fb->panel = devm_kzalloc(&fb->dev->dev, sizeof(*fb->panel), GFP_KERNEL);
> + if (!fb->panel)
> + return -ENOMEM;
> +
> + err = of_get_fb_videomode(node, &fb->panel->mode, OF_USE_NATIVE_MODE);
> + if (err)
> + return err;
> +
> + len = clcdfb_snprintf_mode(NULL, 0, &fb->panel->mode);
> + mode_name = devm_kzalloc(&fb->dev->dev, len + 1, GFP_KERNEL);
> + clcdfb_snprintf_mode(mode_name, len + 1, &fb->panel->mode);
> + fb->panel->mode.name = mode_name;
> +
> + err = of_property_read_u32(node, "max-memory-bandwidth",
> + &max_bandwidth);
> + if (!err)
> + fb->panel->bpp = 8 * max_bandwidth / (fb->panel->mode.xres *
> + fb->panel->mode.yres * fb->panel->mode.refresh);
> + else
> + fb->panel->bpp = 32;
> +
> +#ifdef CONFIG_CPU_BIG_ENDIAN
if (IS_ENABLED(xxx))
> + fb->panel->cntl |= CNTL_BEBO;
> +#endif
> + fb->panel->width = -1;
> + fb->panel->height = -1;
> +
> + err = of_property_read_u32_array(node, "arm,pl11x,panel-data-pads",
> + pads, ARRAY_SIZE(pads));
> + if (err)
> + return err;
> +
> + /* Find first connected pad - its type determines the panel */
> + for (i = 0; i < CLCD_PADS_NUM; i++)
> + if (pads[i] && CLCD_PAD_IS_TFT(pads[i]))
> + return clcdfb_of_init_tft_panel(fb, pads);
> +
> + return -EINVAL;
> +}
> +
> +static int clcdfb_of_vram_setup(struct clcd_fb *fb)
> +{
> + int err;
> + u32 values[2];
> + phys_addr_t phys_base;
> + size_t size;
> +
> + err = clcdfb_of_init_display(fb);
> + if (err)
> + return err;
> +
> + err = of_property_read_u32_array(fb->dev->dev.of_node,
> + "arm,pl11x,framebuffer-base",
> + values, ARRAY_SIZE(values));
> + if (err)
> + return err;
> +
> + phys_base = values[0];
> + size = values[1];
> +
> + fb->fb.screen_base = ioremap(phys_base, size);
> + if (!fb->fb.screen_base)
> + return -ENOMEM;
> +
> + fb->fb.fix.smem_start = phys_base;
> + fb->fb.fix.smem_len = size;
> +
> + return 0;
> +}
> +
> +static int clcdfb_of_vram_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
> +{
> + unsigned long off, user_size, kernel_size;
> +
> + off = vma->vm_pgoff << PAGE_SHIFT;
> + user_size = vma->vm_end - vma->vm_start;
> + kernel_size = fb->fb.fix.smem_len;
> +
> + if (off >= kernel_size || user_size > (kernel_size - off))
> + return -ENXIO;
> +
> + return remap_pfn_range(vma, vma->vm_start,
> + __phys_to_pfn(fb->fb.fix.smem_start) + vma->vm_pgoff,
> + user_size,
> + pgprot_writecombine(vma->vm_page_prot));
> +}
> +
> +static void clcdfb_of_vram_remove(struct clcd_fb *fb)
> +{
> + iounmap(fb->fb.screen_base);
> +}
> +
> +static int clcdfb_of_dma_setup(struct clcd_fb *fb)
> +{
> + unsigned long framesize;
> + dma_addr_t dma;
> + int err;
> +
> + err = clcdfb_of_init_display(fb);
> + if (err)
> + return err;
> +
> + framesize = fb->panel->mode.xres * fb->panel->mode.yres *
> + fb->panel->bpp / 8;
> + fb->fb.screen_base = dma_alloc_writecombine(&fb->dev->dev, framesize,
> + &dma, GFP_KERNEL);
> + if (!fb->fb.screen_base)
> + return -ENOMEM;
> +
> + fb->fb.fix.smem_start = dma;
> + fb->fb.fix.smem_len = framesize;
> +
> + return 0;
> +}
> +
> +static int clcdfb_of_dma_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
> +{
> + return dma_mmap_writecombine(&fb->dev->dev, vma, fb->fb.screen_base,
> + fb->fb.fix.smem_start, fb->fb.fix.smem_len);
> +}
> +
> +static void clcdfb_of_dma_remove(struct clcd_fb *fb)
> +{
> + dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
> + fb->fb.screen_base, fb->fb.fix.smem_start);
> +}
> +
> +static struct clcd_board *clcdfb_of_get_board(struct amba_device *dev)
> +{
> + struct clcd_board *board = devm_kzalloc(&dev->dev, sizeof(*board),
> + GFP_KERNEL);
> + struct device_node *node = dev->dev.of_node;
> +
> + if (!board)
> + return NULL;
> +
> + board->name = of_node_full_name(node);
> + board->caps = CLCD_CAP_ALL;
> + board->check = clcdfb_check;
> + board->decode = clcdfb_decode;
> + if (of_find_property(node, "arm,pl11x,framebuffer-base", NULL)) {
> + board->setup = clcdfb_of_vram_setup;
> + board->mmap = clcdfb_of_vram_mmap;
> + board->remove = clcdfb_of_vram_remove;
> + } else {
> + board->setup = clcdfb_of_dma_setup;
> + board->mmap = clcdfb_of_dma_mmap;
> + board->remove = clcdfb_of_dma_remove;
> + }
> +
> + return board;
> +}
> +#else
> +static struct clcd_board *clcdfb_of_get_board(struct amba_dev *dev)
> +{
> + return NULL;
> +}
> +#endif
> +
> static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
> {
> struct clcd_board *board = dev->dev.platform_data;
> @@ -549,6 +814,9 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
> int ret;
>
> if (!board)
> + board = clcdfb_of_get_board(dev);
> +
> + if (!board)
> return -EINVAL;
>
> ret = amba_request_regions(dev, NULL);
> --
> 1.8.1.2
>
>
^ permalink raw reply
* [PATCH V5 0/5] Generic PHY driver for the Exynos SoC MIPI CSI-2/DSI DPHYs
From: Sylwester Nawrocki @ 2013-09-28 19:27 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds a simple driver for the Samsung S5P/Exynos SoC
series MIPI CSI-2 receiver (MIPI CSIS) and MIPI DSI transmitter (MIPI
DSIM) DPHYs, using the generic PHY framework. Previously the MIPI
CSIS and MIPI DSIM used a platform callback to control the PHY power
enable and reset bits. This non-generic platform code supporting only
limited set of SoCs is now removed.
This completes migration to the device tree of the Exynos/S5P MIPI CSI
slave device driver.
Changes since v4:
- updated to the latest version of the generic PHY framework - removed
PHY labels from the platform data structure. There is already no need
for non-dt support in this PHY driver so the platform data where any
struct phy_init_data would be passed is not added.
Changes since v3 (only patch 1/5):
- replaced spin_(un)lock_irq_{save,restore} with spin_{lock,unlock}.
- DT binding file renamed to samsung-phy.txt, so it can be used for
other PHYs as well,
- removed <linux/delay.h> inclusion,
- added missing spin_lock_init().
Changes since v2:
- adapted to the generic PHY API v9: use phy_set/get_drvdata(),
- fixed of_xlate callback to return ERR_PTR() instead of NULL,
- namespace cleanup, put "GPL v2" as MODULE_LICENSE, removed pr_debug,
- removed phy id check in __set_phy_state().
Changes since v1:
- enabled build as module and with CONFIG_OF disabled,
- added phy_id enum,
- of_address_to_resource() replaced with platform_get_resource(),
- adapted to changes in the PHY API v7, v8 - added phy labels,
- added MODULE_DEVICE_TABLE() entry,
- the driver file renamed to phy-exynos-mipi-video.c,
- changed DT compatible string to "samsung,s5pv210-mipi-video-phy",
- corrected the compatible property's description.
- patch 3/5 "video: exynos_dsi: Use generic PHY driver" replaced
with a patch modifying the MIPI DSIM driver which is currently
in mainline.
Sylwester Nawrocki (5):
ARM: dts: Add MIPI PHY node to exynos4.dtsi
phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
[media] exynos4-is: Use the generic MIPI CSIS PHY driver
video: exynos_mipi_dsim: Use the generic PHY driver
ARM: Samsung: Remove the MIPI PHY setup code
.../devicetree/bindings/phy/samsung-phy.txt | 14 ++
arch/arm/boot/dts/exynos4.dtsi | 10 +
arch/arm/mach-exynos/include/mach/regs-pmu.h | 5 -
arch/arm/mach-s5pv210/include/mach/regs-clock.h | 4 -
arch/arm/plat-samsung/Kconfig | 5 -
arch/arm/plat-samsung/Makefile | 1 -
arch/arm/plat-samsung/setup-mipiphy.c | 60 -------
drivers/media/platform/exynos4-is/Kconfig | 2 +-
drivers/media/platform/exynos4-is/mipi-csis.c | 13 +-
drivers/phy/Kconfig | 6 +
drivers/phy/Makefile | 7 +-
drivers/phy/phy-exynos-mipi-video.c | 176 ++++++++++++++++++++
drivers/video/exynos/Kconfig | 1 +
drivers/video/exynos/exynos_mipi_dsi.c | 19 +-
include/linux/platform_data/mipi-csis.h | 9 -
include/video/exynos_mipi_dsim.h | 5 +-
16 files changed, 234 insertions(+), 103 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/samsung-phy.txt
delete mode 100644 arch/arm/plat-samsung/setup-mipiphy.c
create mode 100644 drivers/phy/phy-exynos-mipi-video.c
--
1.7.4.1
^ permalink raw reply
* [PATCH V5 1/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi
From: Sylwester Nawrocki @ 2013-09-28 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1380396467-29278-1-git-send-email-s.nawrocki@samsung.com>
Add PHY provider node for the MIPI CSIS and MIPI DSIM PHYs.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
arch/arm/boot/dts/exynos4.dtsi | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index caadc02..a73eeb5 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -49,6 +49,12 @@
reg = <0x10000000 0x100>;
};
+ mipi_phy: video-phy@10020710 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ reg = <0x10020710 8>;
+ #phy-cells = <1>;
+ };
+
pd_mfc: mfc-power-domain@10023C40 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C40 0x20>;
@@ -161,6 +167,8 @@
clock-names = "csis", "sclk_csis";
bus-width = <4>;
samsung,power-domain = <&pd_cam>;
+ phys = <&mipi_phy 0>;
+ phy-names = "csis";
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
@@ -174,6 +182,8 @@
clock-names = "csis", "sclk_csis";
bus-width = <2>;
samsung,power-domain = <&pd_cam>;
+ phys = <&mipi_phy 2>;
+ phy-names = "csis";
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
--
1.7.4.1
^ permalink raw reply related
* [PATCH V5 2/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Sylwester Nawrocki @ 2013-09-28 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1380396467-29278-1-git-send-email-s.nawrocki@samsung.com>
Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2
receiver and MIPI DSI transmitter DPHYs.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
Changes since v4:
- updated to latest version of the PHY framework - removed PHY
labels.
The individual driver symbols in drivers/phy/Kconfig should
presumably be prefixed with, e.g. PHY_. This is something that
perhaps could be done as a follow up patch.
---
.../devicetree/bindings/phy/samsung-phy.txt | 14 ++
drivers/phy/Kconfig | 6 +
drivers/phy/Makefile | 7 +-
drivers/phy/phy-exynos-mipi-video.c | 176 ++++++++++++++++++++
4 files changed, 200 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/samsung-phy.txt
create mode 100644 drivers/phy/phy-exynos-mipi-video.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
new file mode 100644
index 0000000..5ff208c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -0,0 +1,14 @@
+Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY
+-------------------------------------------------
+
+Required properties:
+- compatible : should be "samsung,s5pv210-mipi-video-phy";
+- reg : offset and length of the MIPI DPHY register set;
+- #phy-cells : from the generic phy bindings, must be 1;
+
+For "samsung,s5pv210-mipi-video-phy" compatible PHYs the second cell in
+the PHY specifier identifies the PHY and its meaning is as follows:
+ 0 - MIPI CSIS 0,
+ 1 - MIPI DSIM 0,
+ 2 - MIPI CSIS 1,
+ 3 - MIPI DSIM 1.
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ac239ac..0062d7e 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,6 +15,12 @@ config GENERIC_PHY
phy users can obtain reference to the PHY. All the users of this
framework should select this config.
+config PHY_EXYNOS_MIPI_VIDEO
+ tristate "S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver"
+ help
+ Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung S5P
+ and EXYNOS SoCs.
+
config OMAP_USB2
tristate "OMAP USB2 PHY Driver"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 0dd8a98..6344053 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -2,6 +2,7 @@
# Makefile for the phy drivers.
#
-obj-$(CONFIG_GENERIC_PHY) += phy-core.o
-obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
-obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
+obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
+obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
+obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
diff --git a/drivers/phy/phy-exynos-mipi-video.c b/drivers/phy/phy-exynos-mipi-video.c
new file mode 100644
index 0000000..b73b86a
--- /dev/null
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -0,0 +1,176 @@
+/*
+ * Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+
+/* MIPI_PHYn_CONTROL register offset: n = 0..1 */
+#define EXYNOS_MIPI_PHY_CONTROL(n) ((n) * 4)
+#define EXYNOS_MIPI_PHY_ENABLE (1 << 0)
+#define EXYNOS_MIPI_PHY_SRESETN (1 << 1)
+#define EXYNOS_MIPI_PHY_MRESETN (1 << 2)
+#define EXYNOS_MIPI_PHY_RESET_MASK (3 << 1)
+
+enum exynos_mipi_phy_id {
+ EXYNOS_MIPI_PHY_ID_CSIS0,
+ EXYNOS_MIPI_PHY_ID_DSIM0,
+ EXYNOS_MIPI_PHY_ID_CSIS1,
+ EXYNOS_MIPI_PHY_ID_DSIM1,
+ EXYNOS_MIPI_PHYS_NUM
+};
+
+#define is_mipi_dsim_phy_id(id) \
+ ((id) = EXYNOS_MIPI_PHY_ID_DSIM0 || (id) = EXYNOS_MIPI_PHY_ID_DSIM1)
+
+struct exynos_mipi_video_phy {
+ spinlock_t slock;
+ struct video_phy_desc {
+ struct phy *phy;
+ unsigned int index;
+ } phys[EXYNOS_MIPI_PHYS_NUM];
+ void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_mipi_video_phy *state,
+ enum exynos_mipi_phy_id id, unsigned int on)
+{
+ void __iomem *addr;
+ u32 reg, reset;
+
+ addr = state->regs + EXYNOS_MIPI_PHY_CONTROL(id / 2);
+
+ if (is_mipi_dsim_phy_id(id))
+ reset = EXYNOS_MIPI_PHY_MRESETN;
+ else
+ reset = EXYNOS_MIPI_PHY_SRESETN;
+
+ spin_lock(&state->slock);
+ reg = readl(addr);
+ if (on)
+ reg |= reset;
+ else
+ reg &= ~reset;
+ writel(reg, addr);
+
+ /* Clear ENABLE bit only if MRESETN, SRESETN bits are not set. */
+ if (on)
+ reg |= EXYNOS_MIPI_PHY_ENABLE;
+ else if (!(reg & EXYNOS_MIPI_PHY_RESET_MASK))
+ reg &= ~EXYNOS_MIPI_PHY_ENABLE;
+
+ writel(reg, addr);
+ spin_unlock(&state->slock);
+ return 0;
+}
+
+#define to_mipi_video_phy(desc) \
+ container_of((desc), struct exynos_mipi_video_phy, phys[(desc)->index]);
+
+static int exynos_mipi_video_phy_power_on(struct phy *phy)
+{
+ struct video_phy_desc *phy_desc = phy_get_drvdata(phy);
+ struct exynos_mipi_video_phy *state = to_mipi_video_phy(phy_desc);
+
+ return __set_phy_state(state, phy_desc->index, 1);
+}
+
+static int exynos_mipi_video_phy_power_off(struct phy *phy)
+{
+ struct video_phy_desc *phy_desc = phy_get_drvdata(phy);
+ struct exynos_mipi_video_phy *state = to_mipi_video_phy(phy_desc);
+
+ return __set_phy_state(state, phy_desc->index, 1);
+}
+
+static struct phy *exynos_mipi_video_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct exynos_mipi_video_phy *state = dev_get_drvdata(dev);
+
+ if (WARN_ON(args->args[0] > EXYNOS_MIPI_PHYS_NUM))
+ return ERR_PTR(-ENODEV);
+
+ return state->phys[args->args[0]].phy;
+}
+
+static struct phy_ops exynos_mipi_video_phy_ops = {
+ .power_on = exynos_mipi_video_phy_power_on,
+ .power_off = exynos_mipi_video_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int exynos_mipi_video_phy_probe(struct platform_device *pdev)
+{
+ struct exynos_mipi_video_phy *state;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct phy_provider *phy_provider;
+ unsigned int i;
+
+ state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ state->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(state->regs))
+ return PTR_ERR(state->regs);
+
+ dev_set_drvdata(dev, state);
+ spin_lock_init(&state->slock);
+
+ phy_provider = devm_of_phy_provider_register(dev,
+ exynos_mipi_video_phy_xlate);
+ if (IS_ERR(phy_provider))
+ return PTR_ERR(phy_provider);
+
+ for (i = 0; i < EXYNOS_MIPI_PHYS_NUM; i++) {
+ struct phy *phy = devm_phy_create(dev,
+ &exynos_mipi_video_phy_ops, NULL);
+ if (IS_ERR(phy)) {
+ dev_err(dev, "failed to create PHY %d\n", i);
+ return PTR_ERR(phy);
+ }
+
+ state->phys[i].phy = phy;
+ state->phys[i].index = i;
+ phy_set_drvdata(phy, &state->phys[i]);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id exynos_mipi_video_phy_of_match[] = {
+ { .compatible = "samsung,s5pv210-mipi-video-phy" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, exynos_mipi_video_phy_of_match);
+
+static struct platform_driver exynos_mipi_video_phy_driver = {
+ .probe = exynos_mipi_video_phy_probe,
+ .driver = {
+ .of_match_table = exynos_mipi_video_phy_of_match,
+ .name = "exynos-mipi-video-phy",
+ .owner = THIS_MODULE,
+ }
+};
+module_platform_driver(exynos_mipi_video_phy_driver);
+
+MODULE_DESCRIPTION("Samsung S5P/EXYNOS SoC MIPI CSI-2/DSI PHY driver");
+MODULE_AUTHOR("Sylwester Nawrocki <s.nawrocki@samsung.com>");
+MODULE_LICENSE("GPL v2");
--
1.7.4.1
^ permalink raw reply related
* [PATCH V5 3/5] [media] exynos4-is: Use the generic MIPI CSIS PHY driver
From: Sylwester Nawrocki @ 2013-09-28 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1380396467-29278-1-git-send-email-s.nawrocki@samsung.com>
Use the generic PHY API instead of the platform callback
to control the MIPI CSIS DPHY.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
Changes since v4:
- updated to latest version of the PHY framework - removed PHY
labels.
---
drivers/media/platform/exynos4-is/Kconfig | 2 +-
drivers/media/platform/exynos4-is/mipi-csis.c | 13 ++++++++++---
include/linux/platform_data/mipi-csis.h | 9 ---------
3 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig
index 53ad0f0..d2d3b4b 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -29,7 +29,7 @@ config VIDEO_S5P_FIMC
config VIDEO_S5P_MIPI_CSIS
tristate "S5P/EXYNOS MIPI-CSI2 receiver (MIPI-CSIS) driver"
depends on REGULATOR
- select S5P_SETUP_MIPIPHY
+ select GENERIC_PHY
help
This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC MIPI-CSI2
receiver (MIPI-CSIS) devices.
diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
index 0914230..9fc2af6 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -20,6 +20,7 @@
#include <linux/memory.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/phy/phy.h>
#include <linux/platform_data/mipi-csis.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
@@ -180,6 +181,7 @@ struct csis_drvdata {
* @sd: v4l2_subdev associated with CSIS device instance
* @index: the hardware instance index
* @pdev: CSIS platform device
+ * @phy: pointer to the CSIS generic PHY
* @regs: mmaped I/O registers memory
* @supplies: CSIS regulator supplies
* @clock: CSIS clocks
@@ -203,6 +205,7 @@ struct csis_state {
struct v4l2_subdev sd;
u8 index;
struct platform_device *pdev;
+ struct phy *phy;
void __iomem *regs;
struct regulator_bulk_data supplies[CSIS_NUM_SUPPLIES];
struct clk *clock[NUM_CSIS_CLOCKS];
@@ -779,8 +782,8 @@ static int s5pcsis_parse_dt(struct platform_device *pdev,
"samsung,csis-wclk");
state->num_lanes = endpoint.bus.mipi_csi2.num_data_lanes;
-
of_node_put(node);
+
return 0;
}
#else
@@ -829,6 +832,10 @@ static int s5pcsis_probe(struct platform_device *pdev)
return -EINVAL;
}
+ state->phy = devm_phy_get(dev, "csis");
+ if (IS_ERR(state->phy))
+ return PTR_ERR(state->phy);
+
mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
state->regs = devm_ioremap_resource(dev, mem_res);
if (IS_ERR(state->regs))
@@ -922,7 +929,7 @@ static int s5pcsis_pm_suspend(struct device *dev, bool runtime)
mutex_lock(&state->lock);
if (state->flags & ST_POWERED) {
s5pcsis_stop_stream(state);
- ret = s5p_csis_phy_enable(state->index, false);
+ ret = phy_power_off(state->phy);
if (ret)
goto unlock;
ret = regulator_bulk_disable(CSIS_NUM_SUPPLIES,
@@ -958,7 +965,7 @@ static int s5pcsis_pm_resume(struct device *dev, bool runtime)
state->supplies);
if (ret)
goto unlock;
- ret = s5p_csis_phy_enable(state->index, true);
+ ret = phy_power_on(state->phy);
if (!ret) {
state->flags |= ST_POWERED;
} else {
diff --git a/include/linux/platform_data/mipi-csis.h b/include/linux/platform_data/mipi-csis.h
index bf34e17..c2fd902 100644
--- a/include/linux/platform_data/mipi-csis.h
+++ b/include/linux/platform_data/mipi-csis.h
@@ -25,13 +25,4 @@ struct s5p_platform_mipi_csis {
u8 hs_settle;
};
-/**
- * s5p_csis_phy_enable - global MIPI-CSI receiver D-PHY control
- * @id: MIPI-CSIS harware instance index (0...1)
- * @on: true to enable D-PHY and deassert its reset
- * false to disable D-PHY
- * @return: 0 on success, or negative error code on failure
- */
-int s5p_csis_phy_enable(int id, bool on);
-
#endif /* __PLAT_SAMSUNG_MIPI_CSIS_H_ */
--
1.7.4.1
^ permalink raw reply related
* [PATCH V5 4/5] video: exynos_mipi_dsim: Use the generic PHY driver
From: Sylwester Nawrocki @ 2013-09-28 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1380396467-29278-1-git-send-email-s.nawrocki@samsung.com>
Use the generic PHY API instead of the platform callback
for the MIPI DSIM DPHY enable/reset control.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Donghwa Lee <dh09.lee@samsung.com>
---
Changes since v4:
- PHY label removed from the platform data structure.
---
drivers/video/exynos/Kconfig | 1 +
drivers/video/exynos/exynos_mipi_dsi.c | 19 ++++++++++---------
include/video/exynos_mipi_dsim.h | 5 ++---
3 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig
index 1b035b2..976594d 100644
--- a/drivers/video/exynos/Kconfig
+++ b/drivers/video/exynos/Kconfig
@@ -16,6 +16,7 @@ if EXYNOS_VIDEO
config EXYNOS_MIPI_DSI
bool "EXYNOS MIPI DSI driver support."
depends on ARCH_S5PV210 || ARCH_EXYNOS
+ select GENERIC_PHY
help
This enables support for MIPI-DSI device.
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index 32e5406..00b3a52 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -30,6 +30,7 @@
#include <linux/interrupt.h>
#include <linux/kthread.h>
#include <linux/notifier.h>
+#include <linux/phy/phy.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
#include <linux/err.h>
@@ -156,8 +157,7 @@ static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power)
exynos_mipi_regulator_enable(dsim);
/* enable MIPI-DSI PHY. */
- if (dsim->pd->phy_enable)
- dsim->pd->phy_enable(pdev, true);
+ phy_power_on(dsim->phy);
clk_enable(dsim->clock);
@@ -373,6 +373,10 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
return ret;
}
+ dsim->phy = devm_phy_get(&pdev->dev, "dsim");
+ if (IS_ERR(dsim->phy))
+ return PTR_ERR(dsim->phy);
+
dsim->clock = devm_clk_get(&pdev->dev, "dsim0");
if (IS_ERR(dsim->clock)) {
dev_err(&pdev->dev, "failed to get dsim clock source\n");
@@ -439,8 +443,7 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
exynos_mipi_regulator_enable(dsim);
/* enable MIPI-DSI PHY. */
- if (dsim->pd->phy_enable)
- dsim->pd->phy_enable(pdev, true);
+ phy_power_on(dsim->phy);
exynos_mipi_update_cfg(dsim);
@@ -504,9 +507,8 @@ static int exynos_mipi_dsi_suspend(struct device *dev)
if (client_drv && client_drv->suspend)
client_drv->suspend(client_dev);
- /* enable MIPI-DSI PHY. */
- if (dsim->pd->phy_enable)
- dsim->pd->phy_enable(pdev, false);
+ /* disable MIPI-DSI PHY. */
+ phy_power_off(dsim->phy);
clk_disable(dsim->clock);
@@ -536,8 +538,7 @@ static int exynos_mipi_dsi_resume(struct device *dev)
exynos_mipi_regulator_enable(dsim);
/* enable MIPI-DSI PHY. */
- if (dsim->pd->phy_enable)
- dsim->pd->phy_enable(pdev, true);
+ phy_power_on(dsim->phy);
clk_enable(dsim->clock);
diff --git a/include/video/exynos_mipi_dsim.h b/include/video/exynos_mipi_dsim.h
index 89dc88a..6a578f8 100644
--- a/include/video/exynos_mipi_dsim.h
+++ b/include/video/exynos_mipi_dsim.h
@@ -216,6 +216,7 @@ struct mipi_dsim_config {
* automatically.
* @e_clk_src: select byte clock source.
* @pd: pointer to MIPI-DSI driver platform data.
+ * @phy: pointer to the MIPI-DSI PHY
*/
struct mipi_dsim_device {
struct device *dev;
@@ -236,6 +237,7 @@ struct mipi_dsim_device {
bool suspended;
struct mipi_dsim_platform_data *pd;
+ struct phy *phy;
};
/*
@@ -248,7 +250,6 @@ struct mipi_dsim_device {
* @enabled: indicate whether mipi controller got enabled or not.
* @lcd_panel_info: pointer for lcd panel specific structure.
* this structure specifies width, height, timing and polarity and so on.
- * @phy_enable: pointer to a callback controlling D-PHY enable/reset
*/
struct mipi_dsim_platform_data {
char lcd_panel_name[PANEL_NAME_SIZE];
@@ -256,8 +257,6 @@ struct mipi_dsim_platform_data {
struct mipi_dsim_config *dsim_config;
unsigned int enabled;
void *lcd_panel_info;
-
- int (*phy_enable)(struct platform_device *pdev, bool on);
};
/*
--
1.7.4.1
^ permalink raw reply related
* [PATCH V5 5/5] ARM: Samsung: Remove the MIPI PHY setup code
From: Sylwester Nawrocki @ 2013-09-28 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1380396467-29278-1-git-send-email-s.nawrocki@samsung.com>
Generic PHY drivers are used to handle the MIPI CSIS and MIPI DSIM
DPHYs so we can remove now unused code at arch/arm/plat-samsung.
In case there is any board file for S5PV210 platforms using MIPI
CSIS/DSIM (not any upstream currently) it should use the generic
PHY API to bind the PHYs to respective PHY consumer drivers and
a platform device for the PHY provider should be defined.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
---
arch/arm/mach-exynos/include/mach/regs-pmu.h | 5 --
arch/arm/mach-s5pv210/include/mach/regs-clock.h | 4 --
arch/arm/plat-samsung/Kconfig | 5 --
arch/arm/plat-samsung/Makefile | 1 -
arch/arm/plat-samsung/setup-mipiphy.c | 60 -----------------------
5 files changed, 0 insertions(+), 75 deletions(-)
delete mode 100644 arch/arm/plat-samsung/setup-mipiphy.c
diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h b/arch/arm/mach-exynos/include/mach/regs-pmu.h
index 57344b7..2cdb63e 100644
--- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
@@ -44,11 +44,6 @@
#define S5P_DAC_PHY_CONTROL S5P_PMUREG(0x070C)
#define S5P_DAC_PHY_ENABLE (1 << 0)
-#define S5P_MIPI_DPHY_CONTROL(n) S5P_PMUREG(0x0710 + (n) * 4)
-#define S5P_MIPI_DPHY_ENABLE (1 << 0)
-#define S5P_MIPI_DPHY_SRESETN (1 << 1)
-#define S5P_MIPI_DPHY_MRESETN (1 << 2)
-
#define S5P_INFORM0 S5P_PMUREG(0x0800)
#define S5P_INFORM1 S5P_PMUREG(0x0804)
#define S5P_INFORM2 S5P_PMUREG(0x0808)
diff --git a/arch/arm/mach-s5pv210/include/mach/regs-clock.h b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
index 032de66..e345584 100644
--- a/arch/arm/mach-s5pv210/include/mach/regs-clock.h
+++ b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
@@ -147,10 +147,6 @@
#define S5P_HDMI_PHY_CONTROL S5P_CLKREG(0xE804)
#define S5P_USB_PHY_CONTROL S5P_CLKREG(0xE80C)
#define S5P_DAC_PHY_CONTROL S5P_CLKREG(0xE810)
-#define S5P_MIPI_DPHY_CONTROL(x) S5P_CLKREG(0xE814)
-#define S5P_MIPI_DPHY_ENABLE (1 << 0)
-#define S5P_MIPI_DPHY_SRESETN (1 << 1)
-#define S5P_MIPI_DPHY_MRESETN (1 << 2)
#define S5P_INFORM0 S5P_CLKREG(0xF000)
#define S5P_INFORM1 S5P_CLKREG(0xF004)
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 7dfba93..ec882ad 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -395,11 +395,6 @@ config S3C24XX_PWM
Support for exporting the PWM timer blocks via the pwm device
system
-config S5P_SETUP_MIPIPHY
- bool
- help
- Compile in common setup code for MIPI-CSIS and MIPI-DSIM devices
-
config S3C_SETUP_CAMIF
bool
help
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 498c7c2..9267d29 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -38,7 +38,6 @@ obj-$(CONFIG_S5P_DEV_UART) += s5p-dev-uart.o
obj-$(CONFIG_SAMSUNG_DEV_BACKLIGHT) += dev-backlight.o
obj-$(CONFIG_S3C_SETUP_CAMIF) += setup-camif.o
-obj-$(CONFIG_S5P_SETUP_MIPIPHY) += setup-mipiphy.o
# DMA support
diff --git a/arch/arm/plat-samsung/setup-mipiphy.c b/arch/arm/plat-samsung/setup-mipiphy.c
deleted file mode 100644
index 66df315..0000000
--- a/arch/arm/plat-samsung/setup-mipiphy.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- *
- * S5P - Helper functions for MIPI-CSIS and MIPI-DSIM D-PHY control
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/export.h>
-#include <linux/kernel.h>
-#include <linux/platform_device.h>
-#include <linux/io.h>
-#include <linux/spinlock.h>
-#include <mach/regs-clock.h>
-
-static int __s5p_mipi_phy_control(int id, bool on, u32 reset)
-{
- static DEFINE_SPINLOCK(lock);
- void __iomem *addr;
- unsigned long flags;
- u32 cfg;
-
- id = max(0, id);
- if (id > 1)
- return -EINVAL;
-
- addr = S5P_MIPI_DPHY_CONTROL(id);
-
- spin_lock_irqsave(&lock, flags);
-
- cfg = __raw_readl(addr);
- cfg = on ? (cfg | reset) : (cfg & ~reset);
- __raw_writel(cfg, addr);
-
- if (on) {
- cfg |= S5P_MIPI_DPHY_ENABLE;
- } else if (!(cfg & (S5P_MIPI_DPHY_SRESETN |
- S5P_MIPI_DPHY_MRESETN) & ~reset)) {
- cfg &= ~S5P_MIPI_DPHY_ENABLE;
- }
-
- __raw_writel(cfg, addr);
- spin_unlock_irqrestore(&lock, flags);
-
- return 0;
-}
-
-int s5p_csis_phy_enable(int id, bool on)
-{
- return __s5p_mipi_phy_control(id, on, S5P_MIPI_DPHY_SRESETN);
-}
-EXPORT_SYMBOL(s5p_csis_phy_enable);
-
-int s5p_dsim_phy_enable(struct platform_device *pdev, bool on)
-{
- return __s5p_mipi_phy_control(pdev->id, on, S5P_MIPI_DPHY_MRESETN);
-}
-EXPORT_SYMBOL(s5p_dsim_phy_enable);
--
1.7.4.1
^ 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