Re: [PATCH] drm/exynos: fix plane-framebuffer linkage
Hi, On 09/17/2014 03:49 PM, Inki Dae wrote: > On 2014년 09월 17일 15:35, Andrzej Hajda wrote: >> Hi, >> >> On 09/16/2014 08:35 AM, Daniel Vetter wrote: >>> On Mon, Sep 15, 2014 at 12:52:17PM -0600, Daniel Drake wrote: Pageflipping currently causes some inconsistencies that lead to crashes. Just run an app that causes a CRTC pageflip in a raw X session and check that it exits cleanly and can be restarted - you'll see crashes like: Unable to handle kernel NULL pointer dereference at virtual address 0334 PC is at exynos_drm_crtc_plane_commit+0x20/0x40 LR is at exynos_drm_crtc_plane_commit+0x20/0x40 [] (exynos_drm_crtc_plane_commit) from [] (exynos_drm_crtc_commit+0x44/0x70) [] (exynos_drm_crtc_commit) from [] (exynos_drm_crtc_mode_set_commit.isra.2+0xb4/0xc4) [] (exynos_drm_crtc_mode_set_commit.isra.2) from [] (exynos_drm_crtc_page_flip+0x140/0x1a8) [] (exynos_drm_crtc_page_flip) from [] (drm_mode_page_flip_ioctl+0x224/0x2dc) [] (drm_mode_page_flip_ioctl) from [] (drm_ioctl+0x338/0x4fc) These crashes happen because drm_plane_force_disable has previously set plane->crtc to NULL. When drm_mode_page_flip_ioctl() is used to flip another framebuffer onto the primary plane, crtc->primary->fb is correctly updated (this is a virtual plane created by plane_helper), but plane->fb is not (this plane is the real one, created by exynos_drm_crtc_create). We then come to handle rmfb of the backbuffer, which the "real" primary plane is incorrectly pointing at. So drm_framebuffer_remove() decides that the buffer is actually active on a plane and force-disables the plane. Ensuring that plane->fb is kept up-to-date solves that issue, but exposes a reference counting problem. Now we see crashes when rmfb is called on the front-buffer, because the rmfb code expects to drop 3 references here, and there are only 2. That can be fixed by adopting the reference management found in omapdrm: Framebuffer references are not taken directly in crtc mode_set context, but rather in the context of updating the plane, which also covers flips. Like omapdrm we also unreference the old framebuffer here. Signed-off-by: Daniel Drake >>> This sounds very much like exynos should switch to universal planes so >>> that the fake primary plane created by the helpers doesn't get in the way. >>> And for chips which already use planes for everything internally this >>> shouldn't be a lot more than a few lines. >>> -Daniel >> >> The patch proposed here of course supersedes my patch fixing fb refcounting. >> But the best solution is to get rid of virtual plane as Daniel Vetter >> stated. >> Daniel (Drake of course :) ) do you want to prepare patch switching to >> universal planes? >> Maybe other volunteers? If not I can try to do it, as it seems quite >> straightforward. > > I think you can do it and you would be a right person to do it. > > Thanks, > Inki Dae > >> >> Regards >> Andrzej >> --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 ++-- drivers/gpu/drm/exynos/exynos_drm_plane.c | 8 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index b68e58f..7aa9dee 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -140,16 +140,8 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode, if (manager->ops->mode_set) manager->ops->mode_set(manager, &crtc->mode); - ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, crtc_w, crtc_h, - x, y, crtc_w, crtc_h); - if (ret) - return ret; - - plane->crtc = crtc; - plane->fb = crtc->primary->fb; - drm_framebuffer_reference(plane->fb); It's problem to add this from commit 25c8b5c3048cb6c98d402ca8d4735ccf910f727c. Chip specific drm driver internally doesn't have to care fb reference count if there is no special case. We should have switched to universal plane at that time. Thanks. - - return 0; + return exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, + crtc_w, crtc_h, x, y, crtc_w, crtc_h); } static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, int y, diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c b/drivers/gpu/drm/exynos/exynos_drm_plane.c index 8371cbd..df27e35 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c @@ -139,6 +139,14 @@ int exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc *crtc,
Re: [PATCHv3 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC
Hello Doug, On Wed, Sep 17, 2014 at 12:15 AM, Doug Anderson wrote: > > I think you can turn off CONFIG_COMMON_CLK_MAX77686 and then this > clock will be left at whatever the bootloader set it to, right? Then > there will be no auto-disabling by the CCF and the RTC will work. Yes, that's how Daniel was working around the issue. > That's one argument for making the clock "optional". > Indeed. > NOTE: I don't think that the builtin RTC is terribly important for any > exynos-based Chromebooks that I'm aware of. We rely on the RTC that's > part of the Maxim PMIC itself and pretty much ignore the one built-in > to the exynos. I think there are some cases it was used (as a > fallback wakeup source in certain test scripts), but nothing very > important. > Ok, I'll post the patch I shared before that makes the rtc to claim the max77802 32kHz clock as "rtc_src" anyways since that is the right thing to do even if the "rtc_src" ends being optional due DT backward compat. > -Doug Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] arm: exynos: Allow rtc alarm and tick wakeup irq for exynos3250.
Hi,
On Wed, Sep 17, 2014 at 8:52 AM, Jonghwa Lee wrote:
> Add rtc alarm and tick irq to wakeup sources in exynos3250.
>
> Signed-off-by: Jonghwa Lee
> Acked-by : Chanwoo choi
> ---
> arch/arm/mach-exynos/pm.c |9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
> index fa7218a..d78dcf9 100644
> --- a/arch/arm/mach-exynos/pm.c
> +++ b/arch/arm/mach-exynos/pm.c
> @@ -66,6 +66,12 @@ static struct sleep_save exynos_core_save[] = {
>
> static u32 exynos_irqwake_intmask = 0x;
>
> +static const struct exynos_wkup_irq exynos3250_wkup_irq[] = {
> + { 105, BIT(1) }, /* RTC alarm */
> + { 106, BIT(2) }, /* RTC tick */
> + { /* sentinel */ },
> +};
> +
> static const struct exynos_wkup_irq exynos4_wkup_irq[] = {
> { 76, BIT(1) }, /* RTC alarm */
> { 77, BIT(2) }, /* RTC tick */
> @@ -81,9 +87,10 @@ static const struct exynos_wkup_irq exynos5250_wkup_irq[]
> = {
> static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
> {
> const struct exynos_wkup_irq *wkup_irq;
> -
> if (soc_is_exynos5250())
> wkup_irq = exynos5250_wkup_irq;
> + else if (soc_is_exynos3250())
> + wkup_irq = exynos3250_wkup_irq;
Don't add anymore soc_is_exynosxxx() checks, please rebase on [1],
which refactors the pm.c to use DT based lookup.
[1] http://www.spinics.net/lists/arm-kernel/msg355266.html
> else
> wkup_irq = exynos4_wkup_irq;
>
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
Hi Laurent, On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote: > Hi Ajay, > > Thank you for the patch. > > I think we're moving in the right direction, but we're not there yet. > > On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote: >> This patch tries to seperate drm_bridge implementation >> into 2 parts, a drm part and a non_drm part. >> >> A set of helper functions are defined in this patch to make >> bridge driver probe independent of the drm flow. >> >> The bridge devices register themselves on a lookup table >> when they get probed by calling "drm_bridge_add_for_lookup". >> >> The parent encoder driver waits till the bridge is available in the >> lookup table(by calling "of_drm_find_bridge") and then continues with >> its initialization. > > Before the introduction of the component framework I would have said this is > the way to go. Now, I think bridges should register themselves as components, > and the DRM master driver should use the component framework to get a > reference to the bridges it needs. Well, I have modified the bridge framework exactly the way Thierry wanted it to be, I mean the same way the current panel framework is. And, I don't think there is a problem with that. What problem are you facing with current bridge implementation? What is the advantage of using the component framework to register bridges? >> The encoder driver should call "drm_bridge_attach_encoder" to pass on >> the drm_device and the encoder pointers to the bridge object. >> >> Now that the drm_device pointer is available, the encoder then calls >> "bridge->funcs->post_encoder_init" to allow the bridge to continue >> registering itself with the drm core. > > This is what really bothers me with DRM bridge. > > The framework assumes that a bridge will always bridge an encoder and a > connector. Beside lacking support for chained bridges, this creates an > artificial split between bridges and encoders by modeling the same components > using drm_encoder or drm_bridge depending on their position in the video > output pipeline. > > I would like to see drm_bridge becoming more self-centric, removing the > awareness of the upstream encoder and downstream connector. I'll give this a > try, but it will conflict with this patch, so I'd like to share opinions and > coordinate efforts sooner than later if possible. I am not really able to understand how you want "drm_bridge" to be. As of now, there are many platforms using drm_bridge and they don't have a problem with current implementation. Regarding chained bridges: Can't you add this once my patchset is merged? As an additional feature? To be honest, I have spent quite sometime for working on this patchset. All I started with was to add drm_panel support to drm_bridge. When I sent the first patchset for that, Daniel, Rob and Thierry raised a concern that current bridge framework itself is not proper and hence they asked me to fix that first. And we have reached till here based on their comments only. Without this patchset, you cannot bring an X server based display on snow and peach_pit. Also, day by day the number of platforms using drm_bridge is increasing. And, I don't really see a problem with the current approach(which is exactly the same way panel framework is). And, I am no decision maker here. I would expect the top guys to comment! Ajay >> Also, non driver model based ptn3460 driver is removed in this patch. >> >> Signed-off-by: Ajay Kumar >> --- >> .../devicetree/bindings/drm/bridge/ptn3460.txt | 27 -- >> drivers/gpu/drm/Makefile |1 + >> drivers/gpu/drm/bridge/Kconfig | 12 +- >> drivers/gpu/drm/bridge/Makefile|2 - >> drivers/gpu/drm/bridge/ptn3460.c | 343 - >> drivers/gpu/drm/drm_bridge.c | 89 + >> drivers/gpu/drm/drm_crtc.c |9 +- >> drivers/gpu/drm/exynos/Kconfig |3 +- >> drivers/gpu/drm/exynos/exynos_dp_core.c| 57 ++-- >> drivers/gpu/drm/exynos/exynos_dp_core.h|1 + >> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |3 +- >> include/drm/bridge/ptn3460.h | 37 --- >> include/drm/drm_crtc.h | 16 +- >> 13 files changed, 147 insertions(+), 453 deletions(-) >> delete mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt >> delete mode 100644 drivers/gpu/drm/bridge/ptn3460.c >> create mode 100644 drivers/gpu/drm/drm_bridge.c >> delete mode 100644 include/drm/bridge/ptn3460.h > > -- > Regards, > > Laurent Pinchart > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
>> >> Before the introduction of the component framework I would have said this is >> the way to go. Now, I think bridges should register themselves as components, >> and the DRM master driver should use the component framework to get a >> reference to the bridges it needs. > Well, I have modified the bridge framework exactly the way Thierry wanted it > to be, I mean the same way the current panel framework is. > And, I don't think there is a problem with that. > What problem are you facing with current bridge implementation? > What is the advantage of using the component framework to register bridges? At this point I'd rather merge something that keep iterating out of tree, if this enables current hw to work and is better than what we have we should merge it, and if we can get interest in using the component framework then we should look at that as a separate problem. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
Hi Ajay, On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote: > On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote: > > Hi Ajay, > > > > Thank you for the patch. > > > > I think we're moving in the right direction, but we're not there yet. > > > > On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote: > >> This patch tries to seperate drm_bridge implementation > >> into 2 parts, a drm part and a non_drm part. > >> > >> A set of helper functions are defined in this patch to make > >> bridge driver probe independent of the drm flow. > >> > >> The bridge devices register themselves on a lookup table > >> when they get probed by calling "drm_bridge_add_for_lookup". > >> > >> The parent encoder driver waits till the bridge is available in the > >> lookup table(by calling "of_drm_find_bridge") and then continues with > >> its initialization. > > > > Before the introduction of the component framework I would have said this > > is the way to go. Now, I think bridges should register themselves as > > components, and the DRM master driver should use the component framework > > to get a reference to the bridges it needs. > > Well, I have modified the bridge framework exactly the way Thierry wanted it > to be, I mean the same way the current panel framework is. > And, I don't think there is a problem with that. > What problem are you facing with current bridge implementation? > What is the advantage of using the component framework to register bridges? There are several advantages. - The component framework has been designed with this exact problem in mind, piecing multiple components into a display device. This patch set introduces yet another framework, without any compelling reason as far as I can see. Today DRM drivers already need to use three different frameworks (component, I2C slave encoder and panel), and we're adding a fourth one to make the mess even messier. This is really a headlong rush, we need to stop and fix the design mistakes. - The component framework solves the probe ordering problem. Bridges can use deferred probing, but when a bridge requires a resources (such as a clock for instance) provided by the display controller, this will break. > >> The encoder driver should call "drm_bridge_attach_encoder" to pass on > >> the drm_device and the encoder pointers to the bridge object. > >> > >> Now that the drm_device pointer is available, the encoder then calls > >> "bridge->funcs->post_encoder_init" to allow the bridge to continue > >> registering itself with the drm core. > > > > This is what really bothers me with DRM bridge. > > > > The framework assumes that a bridge will always bridge an encoder and a > > connector. Beside lacking support for chained bridges, this creates an > > artificial split between bridges and encoders by modeling the same > > components using drm_encoder or drm_bridge depending on their position in > > the video output pipeline. > > > > I would like to see drm_bridge becoming more self-centric, removing the > > awareness of the upstream encoder and downstream connector. I'll give this > > a try, but it will conflict with this patch, so I'd like to share > > opinions and coordinate efforts sooner than later if possible. > > I am not really able to understand how you want "drm_bridge" to be. > As of now, there are many platforms using drm_bridge and they don't > have a problem with current implementation. > Regarding chained bridges: Can't you add this once my patchset is merged? > As an additional feature? Yes, as I mentioned in another e-mail this can be fixed later. I want to start discussing it though. > To be honest, I have spent quite sometime for working on this patchset. > All I started with was to add drm_panel support to drm_bridge. > When I sent the first patchset for that, Daniel, Rob and Thierry raised a > concern that current bridge framework itself is not proper and hence > they asked me to fix that first. And we have reached till here based on > their comments only. > > Without this patchset, you cannot bring an X server > based display on snow and peach_pit. Also, day by day the number of > platforms using drm_bridge is increasing. That's exactly why I'd like to use the component framework now, as the conversion will become more complex as time goes by. > And, I don't really see a problem with the current approach(which is exactly > the same way panel framework is). And, I am no decision maker here. I would > expect the top guys to comment! -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 00/12] drm/exynos: few patches to enhance bridge chip support
On Tue, Sep 16, 2014 at 6:14 PM, Javier Martinez Canillas wrote: > [adding Laurent Pinchart to cc who had concerns with a previous > version of this patch-set] > > Hello Ajay, > > On Wed, Aug 27, 2014 at 4:29 PM, Ajay Kumar wrote: >> This series is based on master branch of Linus tree at: >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> >> I have tested this after adding few DT changes for exynos5250-snow and >> exynos5420-peach-pit boards. >> >> The V4 series of this particular patchset was also tested by: >> Rahul Sharma >> Javier Martinez Canillas >> >> Changes since V2: >> -- Address comments from Jingoo Han for ps8622 driver >> -- Address comments from Daniel, Rob and Thierry regarding >>bridge chaining >> -- Address comments from Thierry regarding the names for >>new drm_panel functions >> >> Changes since V3: >> -- Remove hotplug based initialization of exynos_dp >> -- Make exynos_dp work directly with drm_panel, remove >>dependency on panel_binder >> -- Minor cleanups in panel_binder and panel_lvds driver >> >> Changes since V4: >> -- Use gpiod interface for panel-lvds and ps8622 drivers. >> -- Address comments from Javier. >> -- Fix compilation issues when PANEL_BINDER is selected as module. >> -- Split Documentation patches from driver patches. >> -- Rebase on top of the tree. >> >> Changes since V5: >> -- Modify bridge drivers to support driver model. >> -- Drop the concept of bridge chain(sincle there are no 2 real >> bridges) >>Hence drop bridge-panel_binder layer. >> -- Drop panel-lvds driver and accomodate the required changes in >>panel-simple driver. >> -- Use gpiod interface in ptn3460 driver. >> -- Address all comments by Thierry Reding for V5 series. >> -- Address comments from Sean Paul for exynos_dp_commit issue. >> >> Changes since V6: >> -- Panel patches were seperated and they are merged already. >> -- Fix few issues with ptn3460, before modifying the bridge core. >> -- Modify drm_bridge as per Thierry's comments for V6 series. >> -- Add drm_bridge changes minimally without breaking existing code. >> -- Add new features for ptn3460, step-by-step. >> -- Address comments from Thierry and Andreas for ptn3460 and ps8622. >> -- Split documentation patches from driver patches. >> > > I've tested your series on an Exynos5420 Peach Pit and an Exynos5250 > Snow Chromebooks and display worked for me on both machines. Great! > I also needed "[PATCH] drm/panel: simple: Add AUO B116XW03 panel > support" [0] which does not apply cleanly on linux-next so you may > want to do a re-spin for that patch. Ok. I will take care of this in next version. > For Snow I also had to disable CONFIG_FB_SIMPLE, otherwise I just saw > a blink on boot and only the backlight remained turned on (no display > output). I don't know if that is expected since IIUC it should be > possible to do a transition from simplefb to a DRM/KMS driver. I don't > have a serial console hooked on this machine so I couldn't debug it > further, sorry. I am just wondering how SIMPLE FB can affect DRM based display. I am not even sure if both can co-exist or not. Is there anything we can do with bootargs instead of CONFIG? Ajay > Also, I saw that Laurent mentioned some concerns today about the > previous version (v6) of your series [1]. I guess he missed this v7 > although AFAIU there was no fundamental change on this one so his > concerns remains? I was really hoping that this could make it to 3.18 > since display support is one of the last major functionalities that is > missing on these machines. > > Best regards, > Javier > > [0]: http://patchwork.ozlabs.org/patch/384744/ > [1]: http://www.spinics.net/lists/linux-samsung-soc/msg36791.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Thierry,
On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote:
> On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
> > On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding wrote:
> > > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
> > >> Am 29.07.2014 13:36, schrieb Thierry Reding:
> > >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
> > >> >> Am 28.07.2014 08:13, schrieb Ajay kumar:
> > >> >>> On 7/27/14, Andreas Färber wrote:
> > >> Am 25.07.2014 21:22, schrieb Ajay Kumar:
> > >> > This series is based on exynos-drm-next branch of Inki Dae's tree
> > >> > at:
> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.
> > >> > git
> > >> >
> > >> > I have tested this after adding few DT changes for
> > >> > exynos5250-snow,
> > >> > exynos5420-peach-pit and exynos5800-peach-pi boards.
> > >>
> > >> I'm trying to test this with a modified exynos5250-spring DT
> > >>
> > >> [...]
> > >>
> > >> >> Unfortunately the most I got on Spring with attached DT was a blank
> > >> >> screen with a white horizontal line in the middle.
> > >> >>
> > >> >> Do I need to specify a specific panel model for Spring?
> > >>
> > >> [...]
> > >>
> > >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00
> > >> >> 2001
> > >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?=
> > >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200
> > >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
> > >> >> MIME-Version: 1.0
> > >> >> Content-Type: text/plain; charset=UTF-8
> > >> >> Content-Transfer-Encoding: 8bit
> > >> >>
> > >> >> Signed-off-by: Ajay Kumar
> > >> >> [AF: Redone for v6]
> > >> >> Signed-off-by: Andreas F??rber
> > >> >> ---
> > >> >>
> > >> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +-
> > >> >> 1 file changed, 31 insertions(+), 1 deletion(-)
> > >> >>
> > >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
> > >> >> b/arch/arm/boot/dts/exynos5250-spring.dts index
> > >> >> 687dfab86bc8..517b1ff2bfdf 100644
> > >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts
> > >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> > >> >> @@ -64,10 +64,14 @@
> > >> >>vdd_pll-supply = <&s5m_ldo8_reg>;
> > >> >>};
> > >> >>
> > >> >> + panel: panel {
> > >> >> + compatible = "simple-panel";
> > >> >> + };
> > >> >
> > >> > You can't do this. "simple-panel" isn't a valid panel model. It
> > >> > should probably be removed from the platform_of_match table in the
> > >> > driver.
> > >>
> > >> Okay, that means the Snow DT is wrong, too:
> > >> https://patchwork.kernel.org/patch/4625441/
> > >>
> > >> And the others specify it as fallback:
> > >> https://patchwork.kernel.org/patch/4625461/
> > >> https://patchwork.kernel.org/patch/4625451/
> > >
> > > A quick grep shows that many (all?) devices that use DRM panels provide
> > > simple-panel as fallback. That's probably fine as long as they also do
> > > provide the specific model. But given that simple-panel does not have a
> > > mode or physical size, I don't think even that makes sense.
> >
> > On snow, the bridge chip provides the display mode instead of the panel.
> > That is why display was working for me.
>
> Okay, I suppose under some circumstances that might make sense. Although
> it's still always the panel that dictates the display timings, so the
> panel node needs to have a panel model specific compatible value with a
> matching entry in the panel-simple driver so that it can even be used in
> setups without a bridge.
>
> One other thing: how does the bridge know which mode to drive? I suspect
> that it can drive more than one mode? Can it freely be configured or
> does it have a predefined set of modes? If the latter, then according to
> what you said above there needs to be a way to configure the bridge (via
> DT?) so that it reports the mode matching the panel. I wonder if that
> should be handled completely in code, so that for example a bridge has a
> panel attached it can use the panel's .get_modes() and select a matching
> mode among the set that it supports.
Yes, pretty please :-) I don't think it would be a good idea to duplicate mode
information in the bridge DT node, as that's not a property of the bridge.
Querying the mode at runtime is in my opinion a much better option, and would
also allow switching between different modes at runtime when that makes sense.
Now, I'm not sure whether it should be the bridge driver querying the panel
driver directly, or the display controller driver doing it and then
configuring the bridge accordingly. The latter seems more generic to me and
doesn't rely on the assumption that the bridge output will always be directly
connected to a panel.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices
On Wed, Sep 17, 2014 at 12:01:50PM +0530, Pankaj Dubey wrote:
> Currently a syscon entity can be only registered directly through a
> platform device that binds to a dedicated syscon driver. However in
> certain use cases it is desirable to make a device used with another
> driver a syscon interface provider.
>
> For example, certain SoCs (e.g. Exynos) contain system controller
> blocks which perform various functions such as power domain control,
> CPU power management, low power mode control, but in addition contain
> certain IP integration glue, such as various signal masks,
> coprocessor power control, etc. In such case, there is a need to have
> a dedicated driver for such system controller but also share registers
> with other drivers. The latter is where the syscon interface is helpful.
>
> In case of DT based platforms, this patch decouples syscon object from
> syscon platform driver, and allows to create syscon objects first time
> when it is required by calling of syscon_regmap_lookup_by APIs and keep
> a list of such syscon objects along with syscon provider device_nodes
> and regmap handles.
>
> For non-DT based platforms, this patch keeps syscon platform driver
> structure where is can be probed and such non-DT based drivers can use
> syscon_regmap_lookup_by_pdev API and get access to regmap handles.
> Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
> we can completly remove platform driver of syscon, and keep only helper
> functions to get regmap handles.
>
> Suggested-by: Arnd Bergmann
> Suggested-by: Tomasz Figa
> Tested-by: Vivek Gautam
> Signed-off-by: Pankaj Dubey
> ---
> V2 of this patchset and related discussion can be found here [1].
>
> Changes since v2:
> - Added back platform device support from syscon, with one change that
>syscon will not be probed for DT based platform.
> - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
>users of syscon will not be broken.
> - Removed unwanted change in syscon.h.
> - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
>Arnd Bergmann.
> - Added Tested-by of Vivek Gautam for testing on Exynos platform.
>
> Changes since v1:
> - Removed of_syscon_unregister function.
> - Modified of_syscon_register function and it will be used by syscon.c
>to create syscon objects whenever required.
> - Removed platform device support from syscon.
> - Removed syscon_regmap_lookup_by_pdevname API support.
> - As there are significant changes w.r.t patchset v1, I am taking over
>author for this patchset from Tomasz Figa.
>
> [1]: https://lkml.org/lkml/2014/9/2/299
>
> drivers/mfd/syscon.c | 78
> --
> 1 file changed, 57 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index ca15878..4a4bad9 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -15,40 +15,49 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> -#include
> #include
> #include
> #include
> #include
> +#include
>
> static struct platform_driver syscon_driver;
>
> +static DEFINE_SPINLOCK(syscon_list_slock);
> +static LIST_HEAD(syscon_list);
> +
> struct syscon {
> + struct device_node *np;
> struct regmap *regmap;
> + struct list_head list;
> };
>
> -static int syscon_match_node(struct device *dev, void *data)
> -{
> - struct device_node *dn = data;
> -
> - return (dev->of_node == dn) ? 1 : 0;
> -}
> +static struct syscon *of_syscon_register(struct device_node *np);
>
> struct regmap *syscon_node_to_regmap(struct device_node *np)
> {
> - struct syscon *syscon;
> - struct device *dev;
> + struct syscon *entry, *syscon = NULL;
>
> - dev = driver_find_device(&syscon_driver.driver, NULL, np,
> - syscon_match_node);
> - if (!dev)
> - return ERR_PTR(-EPROBE_DEFER);
> + spin_lock(&syscon_list_slock);
>
> - syscon = dev_get_drvdata(dev);
> + list_for_each_entry(entry, &syscon_list, list)
> + if (entry->np == np) {
> + syscon = entry;
> + break;
> + }
>
> - return syscon->regmap;
> + spin_unlock(&syscon_list_slock);
> +
> + if (!syscon)
> + syscon = of_syscon_register(np);
> +
> + if (!IS_ERR(syscon))
> + return syscon->regmap;
> +
> + return ERR_CAST(syscon);
> }
> EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
>
> @@ -110,17 +119,45 @@ struct regmap *syscon_regmap_lookup_by_phandle(struct
> device_node *np,
> }
> EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle);
>
> -static const struct of_device_id of_syscon_match[] = {
> - { .compatible = "syscon", },
> - { },
> -};
> -
> static struct regmap_config syscon_regmap_config = {
> .reg_bits = 32,
> .val_bits = 32,
> .reg_stride = 4,
> };
>
> +static struct sys
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Laurent,
Please find the latest series here:
http://www.spinics.net/lists/dri-devel/msg66740.html
On Wed, Sep 17, 2014 at 3:23 PM, Laurent Pinchart
wrote:
> Hi Thierry,
>
> On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote:
>> On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
>> > On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding wrote:
>> > > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
>> > >> Am 29.07.2014 13:36, schrieb Thierry Reding:
>> > >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
>> > >> >> Am 28.07.2014 08:13, schrieb Ajay kumar:
>> > >> >>> On 7/27/14, Andreas Färber wrote:
>> > >> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>> > >> > This series is based on exynos-drm-next branch of Inki Dae's tree
>> > >> > at:
>> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.
>> > >> > git
>> > >> >
>> > >> > I have tested this after adding few DT changes for
>> > >> > exynos5250-snow,
>> > >> > exynos5420-peach-pit and exynos5800-peach-pi boards.
>> > >>
>> > >> I'm trying to test this with a modified exynos5250-spring DT
>> > >>
>> > >> [...]
>> > >>
>> > >> >> Unfortunately the most I got on Spring with attached DT was a blank
>> > >> >> screen with a white horizontal line in the middle.
>> > >> >>
>> > >> >> Do I need to specify a specific panel model for Spring?
>> > >>
>> > >> [...]
>> > >>
>> > >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00
>> > >> >> 2001
>> > >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?=
>> > >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200
>> > >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
>> > >> >> MIME-Version: 1.0
>> > >> >> Content-Type: text/plain; charset=UTF-8
>> > >> >> Content-Transfer-Encoding: 8bit
>> > >> >>
>> > >> >> Signed-off-by: Ajay Kumar
>> > >> >> [AF: Redone for v6]
>> > >> >> Signed-off-by: Andreas F??rber
>> > >> >> ---
>> > >> >>
>> > >> >> arch/arm/boot/dts/exynos5250-spring.dts | 32 +-
>> > >> >> 1 file changed, 31 insertions(+), 1 deletion(-)
>> > >> >>
>> > >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
>> > >> >> b/arch/arm/boot/dts/exynos5250-spring.dts index
>> > >> >> 687dfab86bc8..517b1ff2bfdf 100644
>> > >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts
>> > >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
>> > >> >> @@ -64,10 +64,14 @@
>> > >> >>vdd_pll-supply = <&s5m_ldo8_reg>;
>> > >> >>};
>> > >> >>
>> > >> >> + panel: panel {
>> > >> >> + compatible = "simple-panel";
>> > >> >> + };
>> > >> >
>> > >> > You can't do this. "simple-panel" isn't a valid panel model. It
>> > >> > should probably be removed from the platform_of_match table in the
>> > >> > driver.
>> > >>
>> > >> Okay, that means the Snow DT is wrong, too:
>> > >> https://patchwork.kernel.org/patch/4625441/
>> > >>
>> > >> And the others specify it as fallback:
>> > >> https://patchwork.kernel.org/patch/4625461/
>> > >> https://patchwork.kernel.org/patch/4625451/
>> > >
>> > > A quick grep shows that many (all?) devices that use DRM panels provide
>> > > simple-panel as fallback. That's probably fine as long as they also do
>> > > provide the specific model. But given that simple-panel does not have a
>> > > mode or physical size, I don't think even that makes sense.
>> >
>> > On snow, the bridge chip provides the display mode instead of the panel.
>> > That is why display was working for me.
>>
>> Okay, I suppose under some circumstances that might make sense. Although
>> it's still always the panel that dictates the display timings, so the
>> panel node needs to have a panel model specific compatible value with a
>> matching entry in the panel-simple driver so that it can even be used in
>> setups without a bridge.
>>
>> One other thing: how does the bridge know which mode to drive? I suspect
>> that it can drive more than one mode? Can it freely be configured or
>> does it have a predefined set of modes? If the latter, then according to
>> what you said above there needs to be a way to configure the bridge (via
>> DT?) so that it reports the mode matching the panel. I wonder if that
>> should be handled completely in code, so that for example a bridge has a
>> panel attached it can use the panel's .get_modes() and select a matching
>> mode among the set that it supports.
>
> Yes, pretty please :-) I don't think it would be a good idea to duplicate mode
> information in the bridge DT node, as that's not a property of the bridge.
> Querying the mode at runtime is in my opinion a much better option, and would
> also allow switching between different modes at runtime when that makes sense.
>
> Now, I'm not sure whether it should be the bridge driver querying the panel
> driver directly, or the display controller driver doing it and then
> configuring the bridge accordingly. The latter seems more generic to me and
> doesn't rely on the a
[PATCH v3 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ohci-exynos.c | 89 +++-
1 file changed, 24 insertions(+), 65 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 7c48e3f..992b28d 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -19,11 +19,8 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
#include "ohci.h"
@@ -38,9 +35,7 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
struct exynos_ohci_hcd {
struct clk *clk;
- struct usb_phy *phy;
- struct usb_otg *otg;
- struct phy *phy_g[PHY_NUMBER];
+ struct phy *phy[PHY_NUMBER];
};
static int exynos_ohci_get_phy(struct device *dev,
@@ -48,56 +43,40 @@ static int exynos_ohci_get_phy(struct device *dev,
{
struct device_node *child;
struct phy *phy;
- int phy_number;
- int ret = 0;
+ int phy_num;
+ int ret;
- /*
-* Getting generic phy:
-* We are keeping both types of phys as a part of transiting OHCI
-* to generic phy framework, so as to maintain backward compatibilty
-* with old DTB too.
-* We fallback to older USB-PHYs when we fail to get generic PHYs.
-*/
+ /* Get the generic phys */
for_each_available_child_of_node(dev->of_node, child) {
- ret = of_property_read_u32(child, "reg", &phy_number);
+ ret = of_property_read_u32(child, "reg", &phy_num);
if (ret) {
dev_err(dev, "Failed to parse device tree\n");
of_node_put(child);
return ret;
}
- if (phy_number >= PHY_NUMBER) {
+ if (phy_num >= PHY_NUMBER) {
dev_err(dev, "Invalid number of PHYs\n");
of_node_put(child);
return -EINVAL;
}
- phy = devm_of_phy_get(dev, child, NULL);
+ exynos_ohci->phy[phy_num] = devm_of_phy_get(dev, child, NULL);
+ phy = exynos_ohci->phy[phy_num];
of_node_put(child);
- if (IS_ERR(phy))
- /* Lets fallback to older USB-PHYs */
- goto usb_phy_old;
- exynos_ohci->phy_g[phy_number] = phy;
- /* Make the older PHYs unavailable */
- exynos_ohci->phy = ERR_PTR(-ENXIO);
- }
-
- return 0;
-
-usb_phy_old:
- exynos_ohci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(exynos_ohci->phy)) {
- ret = PTR_ERR(exynos_ohci->phy);
- if (ret != -ENXIO && ret != -ENODEV) {
- dev_err(dev, "no usb2 phy configured\n");
- return ret;
+ if (IS_ERR(phy)) {
+ ret = PTR_ERR(phy);
+ if (ret == -EPROBE_DEFER) {
+ return ret;
+ } else if (ret != -ENOSYS && ret != -ENODEV) {
+ dev_err(dev,
+ "Error retrieving usb2 phy: %d\n", ret);
+ return PTR_ERR(phy);
+ }
}
- dev_dbg(dev, "Failed to get usb2 phy\n");
- } else {
- exynos_ohci->otg = exynos_ohci->phy->otg;
}
- return ret;
+ return 0;
}
static int exynos_ohci_phy_enable(struct device *dev)
@@ -107,16 +86,13 @@ static int exynos_ohci_phy_enable(struct device *dev)
int i;
int ret = 0;
- if (!IS_ERR(exynos_ohci->phy))
- return usb_phy_init(exynos_ohci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ohci->phy_g[i]))
- ret = phy_power_on(exynos_ohci->phy_g[i]);
+ if (!IS_ERR(exynos_ohci->phy[i]))
+ ret = phy_power_on(exynos_ohci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
- if (!IS_ERR(exynos_ohci->phy_g[i]))
- phy_power_off(exynos_ohci->phy_g[i]);
+ if (!IS_ERR(exynos_ohci->phy[i]))
+ phy_power_off(exynos_ohci->phy[i]);
return ret;
}
@@ -127,14 +103,9 @@ static void exynos_ohci_phy_disable(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
int i;
- if (!IS_ERR(exynos_ohci->phy)) {
- usb_phy_shutdown(exynos_ohci->phy);
- return;
- }
-
for (i = 0; i < PHY_NUMBER;
[PATCH v3 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ehci-exynos.c | 81
1 file changed, 23 insertions(+), 58 deletions(-)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 2eed9a4..99c5f5f 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
#include "ehci.h"
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
struct exynos_ehci_hcd {
struct clk *clk;
- struct usb_phy *phy;
- struct usb_otg *otg;
- struct phy *phy_g[PHY_NUMBER];
+ struct phy *phy[PHY_NUMBER];
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
@@ -59,49 +54,39 @@ static int exynos_ehci_get_phy(struct device *dev,
{
struct device_node *child;
struct phy *phy;
- int phy_number;
- int ret = 0;
+ int phy_num;
+ int ret;
for_each_available_child_of_node(dev->of_node, child) {
- ret = of_property_read_u32(child, "reg", &phy_number);
+ ret = of_property_read_u32(child, "reg", &phy_num);
if (ret) {
dev_err(dev, "Failed to parse device tree\n");
of_node_put(child);
return ret;
}
- if (phy_number >= PHY_NUMBER) {
+ if (phy_num >= PHY_NUMBER) {
dev_err(dev, "Invalid number of PHYs\n");
of_node_put(child);
return -EINVAL;
}
- phy = devm_of_phy_get(dev, child, NULL);
+ exynos_ehci->phy[phy_num] = devm_of_phy_get(dev, child, NULL);
+ phy = exynos_ehci->phy[phy_num];
of_node_put(child);
- if (IS_ERR(phy))
- /* Lets fallback to older USB-PHYs */
- goto usb_phy_old;
- exynos_ehci->phy_g[phy_number] = phy;
- /* Make the older PHYs unavailable */
- exynos_ehci->phy = ERR_PTR(-ENXIO);
- }
-
- return 0;
-
-usb_phy_old:
- exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(exynos_ehci->phy)) {
- ret = PTR_ERR(exynos_ehci->phy);
- if (ret != -ENXIO && ret != -ENODEV) {
- dev_err(dev, "no usb2 phy configured\n");
- return ret;
+ if (IS_ERR(phy)) {
+ ret = PTR_ERR(phy);
+ if (ret == -EPROBE_DEFER) {
+ return ret;
+ } else if (ret != -ENOSYS && ret != -ENODEV) {
+ dev_err(dev,
+ "Error retrieving usb2 phy: %d\n", ret);
+ return PTR_ERR(phy);
+ }
}
- dev_dbg(dev, "Failed to get usb2 phy\n");
- } else {
- exynos_ehci->otg = exynos_ehci->phy->otg;
}
- return ret;
+ return 0;
}
static int exynos_ehci_phy_enable(struct device *dev)
@@ -111,16 +96,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
- if (!IS_ERR(exynos_ehci->phy))
- return usb_phy_init(exynos_ehci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ehci->phy_g[i]))
- ret = phy_power_on(exynos_ehci->phy_g[i]);
+ if (!IS_ERR(exynos_ehci->phy[i]))
+ ret = phy_power_on(exynos_ehci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
- if (!IS_ERR(exynos_ehci->phy_g[i]))
- phy_power_off(exynos_ehci->phy_g[i]);
+ if (!IS_ERR(exynos_ehci->phy[i]))
+ phy_power_off(exynos_ehci->phy[i]);
return ret;
}
@@ -131,14 +113,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
- if (!IS_ERR(exynos_ehci->phy)) {
- usb_phy_shutdown(exynos_ehci->phy);
- return;
- }
-
for (i = 0; i < PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ehci->phy_g[i]))
- phy_power_off(exynos_ehci->phy_g[i]);
+ if (!IS_ERR(exynos_ehci->phy[i]))
+ phy_power_off(exynos_ehci->phy[i]);
}
static void exynos_setup_vbus_gpio(struct device *dev)
@@ -231,9 +208,6 @@ skip_ph
RE: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices
Hi,
On Wednesday, September 17, 2014, Dong Aisheng Wrote,
> >
> > +static struct syscon *of_syscon_register(struct device_node *np) {
> > + struct syscon *syscon;
> > + struct regmap *regmap;
> > + void __iomem *base;
> > +
> > + if (!of_device_is_compatible(np, "syscon"))
> > + return ERR_PTR(-EINVAL);
> > +
> > + syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
> > + if (!syscon)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + base = of_iomap(np, 0);
> > + if (!base)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + regmap = regmap_init_mmio(NULL, base, &syscon_regmap_config);
>
> Does a NULL device pointer work?
Yes, it is safe, at least we are able to test on Exynos based SoC.
I have tested it with kgene/for-next kernel on Exynos3250.
Also it has been tested on Exynos5250 based Snow board with 3.17-rc5 based
kernel
by Vivek Gautam.
Patch V2 also has been tested by "Borris Brezillon" on AT91 platform.
> I just tested on MX6SX SDB board and it seemed crashed at here in
regmap_init
> function.
>
Can you please provide crash log which can give more information about the
crash?
Thanks,
Pankaj Dubey
> Regards
> Dong Aisheng
>
> > + if (IS_ERR(regmap)) {
> > + pr_err("regmap init failed\n");
> > + return ERR_CAST(regmap);
> > + }
> > +
> > + syscon->regmap = regmap;
> > + syscon->np = np;
> > +
> > + spin_lock(&syscon_list_slock);
> > + list_add_tail(&syscon->list, &syscon_list);
> > + spin_unlock(&syscon_list_slock);
> > +
> > + return syscon;
> > +}
> > +
> > static int syscon_probe(struct platform_device *pdev) {
> > struct device *dev = &pdev->dev;
> > @@ -167,7 +204,6 @@ static struct platform_driver syscon_driver = {
> > .driver = {
> > .name = "syscon",
> > .owner = THIS_MODULE,
> > - .of_match_table = of_syscon_match,
> > },
> > .probe = syscon_probe,
> > .id_table = syscon_ids,
> > --
> > 1.7.9.5
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] usb: host: ehci/ohci-exynos: phy cleanup
Cleaning up the phy getting sequence in ehci-exynos and ohci-exynos drivers. Hi Alan, Jingoo, I have not imported the Acked-by and Reviewed-by from you guys, from V2 version of this patch series, since this version is now rebased on the already available commit in usb-next - "usb: ehci/ohci-exynos: Fix PHY getting sequence". Please feel free to comment on it and add your Acked-by's and Reviewed-by's. Changes since v2: - Rebased on top of usb-next branch, which now has 'usb: ehci/ohci-exynos: Fix PHY getting sequence' patch. Changes since v1: - This patch was part of the series "[PATCH 0/7] usb-phy: samsung: Cleanup the unused drivers" https://lkml.org/lkml/2014/8/14/235. I have dropped the phy cleanup patches from that series- Patches 1-5. - Rebased this patch on top of 3.17-rc1. Vivek Gautam (2): usb: host: ehci-exynos: Remove unnecessary usb-phy support usb: host: ohci-exynos: Remove unnecessary usb-phy support drivers/usb/host/ehci-exynos.c | 81 +++- drivers/usb/host/ohci-exynos.c | 89 +++- 2 files changed, 47 insertions(+), 123 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] drm/exynos: initialization/deinitialization fixes
On 2014년 09월 09일 22:16, Andrzej Hajda wrote: > This set of patches contains fixes of initialization and deinitialization > code of exynos_drm core and components. > It is based on exynos-drm-next branch. > > Patchset has been tested on trats and universal_c210 platforms. Applied all patches except patch #5. As of now, it seems good to merge also patch #5 if you couldn't post next version of that patch until the end of this week. In this case, I will have a pull request including that patch so that we can fix it up correctly later. Give me your opinion if there is other plan. Thanks, Inki Dae > > Regards > Andrzej > > > Andrzej Hajda (9): > drm/exynos/ipp: traverse ipp drivers list safely > drm/exynos: fix drm driver de-initialization order > drm/exynos/fbdev: fix fbdev gem object cleanup > drm/exynos/fb: free exynos framebuffer on error > drm/exynos/crtc: fix framebuffer reference sequence > drm/exynos/dsi: unregister connector on removal > drm/exynos/dpi: unregister connector and panel on removal > drm/exynos/dp: unregister connector on removal > drm/exynos/hdmi: unregister connector on removal > > drivers/gpu/drm/exynos/exynos_dp_core.c | 4 +++- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 ++ > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 6 +- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 ++--- > drivers/gpu/drm/exynos/exynos_drm_fb.c| 1 + > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 --- > drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 ++-- > drivers/gpu/drm/exynos/exynos_hdmi.c | 4 +++- > 9 files changed, 30 insertions(+), 15 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] s3c RTC fix for Exynos Chromebooks
Hello Kukjin,
commit 546b117fdf17 ("rtc: s3c: add support for RTC of Exynos3250 SoC")
added an "rtc_src" DT property for the Samsung's S3C Real Time Clock
controller that specifies the 32.768 kHz clock that uses the RTC as
its source clock but this breaks the s3c RTC on Exynos Chromebooks
because the rtc device node does not define the "rtc_src" clock.
It was working before only because the source clock was not disabled
by the kernel since the CCF didn't know about it. But once the clock
is known, the CCF disables the clock and does not work so define the
"rtc_src" clock to make the s3c-rtc driver obtain it and kept enabled.
This series makes the s3c RTC to claim its source clock on the Snow
and Peach boards but other Samsung boards will have the same issue.
The following patches are meant to be for the 3.18 rc cycle once
3.18-rc1 is released.
Javier Martinez Canillas (2):
ARM: dts: Add rtc_src clk for s3c-rtc on exynos Peach boards
ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow
arch/arm/boot/dts/exynos5250-snow.dts | 5 -
arch/arm/boot/dts/exynos5420-peach-pit.dts | 5 -
arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 -
3 files changed, 12 insertions(+), 3 deletions(-)
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow
commit 546b117fdf17 ("rtc: s3c: add support for RTC of Exynos3250 SoC")
added an "rtc_src" DT property for the Samsung's S3C Real Time Clock
controller that specifies the 32.768 kHz clock that uses the RTC as its
source clock. In the case of the Exynos5250 based Snow board, the Maxim
77686 32kHz AP clock is used as the source clock.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5250-snow.dts | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index e51fcef..56eec56 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -10,6 +10,7 @@
/dts-v1/;
#include
+#include
#include "exynos5250.dtsi"
/ {
@@ -29,6 +30,8 @@
rtc@101E {
status = "okay";
+ clocks = <&clock CLK_RTC>, <&max77686 MAX77686_CLK_AP>;
+ clock-names = "rtc", "rtc_src";
};
pinctrl@1140 {
@@ -350,7 +353,7 @@
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <378000>;
- max77686@09 {
+ max77686: max77686@09 {
compatible = "maxim,max77686";
interrupt-parent = <&gpx3>;
interrupts = <2 0>;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: Add rtc_src clk for s3c-rtc on exynos Peach boards
commit 546b117fdf17 ("rtc: s3c: add support for RTC of Exynos3250 SoC")
added an "rtc_src" DT property for the Samsung's S3C Real Time Clock
controller that specifies the 32.768 kHz clock that uses the RTC as its
source clock. In the case of the Peach Pit and Pi machines, the Maxim
77802 32kHz AP clock is used as the source clock.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 5 -
arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 9a23382..bfd189e 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "exynos5420.dtsi"
/ {
@@ -151,7 +152,7 @@
status = "okay";
clock-frequency = <40>;
- max77802-pmic@9 {
+ max77802: max77802-pmic@9 {
compatible = "maxim,max77802";
interrupt-parent = <&gpx3>;
interrupts = <1 IRQ_TYPE_NONE>;
@@ -727,6 +728,8 @@
&rtc {
status = "okay";
+ clocks = <&clock CLK_RTC>, <&max77802 MAX77802_CLK_32K_AP>;
+ clock-names = "rtc", "rtc_src";
};
&spi_2 {
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 1d31c81..84ec1ce 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "exynos5800.dtsi"
/ {
@@ -150,7 +151,7 @@
status = "okay";
clock-frequency = <40>;
- max77802-pmic@9 {
+ max77802: max77802-pmic@9 {
compatible = "maxim,max77802";
interrupt-parent = <&gpx3>;
interrupts = <1 IRQ_TYPE_NONE>;
@@ -715,6 +716,8 @@
&rtc {
status = "okay";
+ clocks = <&clock CLK_RTC>, <&max77802 MAX77802_CLK_32K_AP>;
+ clock-names = "rtc", "rtc_src";
};
&spi_2 {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On 27/08/14 17:39, Ajay Kumar wrote:
> Add documentation for DT properties supported by ps8622/ps8625
> eDP-LVDS converter.
>
> Signed-off-by: Ajay Kumar
> ---
> .../devicetree/bindings/video/bridge/ps8622.txt| 20
>
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
>
> diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
> b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
> new file mode 100644
> index 000..0ec8172
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
> @@ -0,0 +1,20 @@
> +ps8622-bridge bindings
> +
> +Required properties:
> + - compatible: "parade,ps8622" or "parade,ps8625"
> + - reg: first i2c address of the bridge
> + - sleep-gpios: OF device-tree gpio specification for PD_ pin.
> + - reset-gpios: OF device-tree gpio specification for RST_ pin.
> +
> +Optional properties:
> + - lane-count: number of DP lanes to use
> + - use-external-pwm: backlight will be controlled by an external PWM
What does this mean? That the backlight support from ps8625 is not used?
If so, maybe "disable-pwm" or something?
> +
> +Example:
> + lvds-bridge@48 {
> + compatible = "parade,ps8622";
> + reg = <0x48>;
> + sleep-gpios = <&gpc3 6 1 0 0>;
> + reset-gpios = <&gpc3 1 1 0 0>;
> + lane-count = <1>;
> + };
>
I wish all new display component bindings would use the video
ports/endpoints to describe the connections. It will be very difficult
to improve the display driver model later if we're missing such critical
pieces from the DT bindings.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v3 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
On Wednesday, September 17, 2014 8:18 PM, Vivek Gautam wrote:
>
> Now that we have completely moved from older USB-PHY drivers
> to newer GENERIC-PHY drivers for PHYs available with USB controllers
> on Exynos series of SoCs, we can remove the support for the same
> in our host drivers too.
>
> Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/usb/host/ehci-exynos.c | 81
>
> 1 file changed, 23 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index 2eed9a4..99c5f5f 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -21,11 +21,8 @@
> #include
> #include
> #include
> -#include
> -#include
> #include
> #include
> -#include
>
> #include "ehci.h"
>
> @@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
>
> struct exynos_ehci_hcd {
> struct clk *clk;
> - struct usb_phy *phy;
> - struct usb_otg *otg;
> - struct phy *phy_g[PHY_NUMBER];
> + struct phy *phy[PHY_NUMBER];
> };
>
> #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd
> *)(hcd_to_ehci(hcd)->priv)
> @@ -59,49 +54,39 @@ static int exynos_ehci_get_phy(struct device *dev,
> {
> struct device_node *child;
> struct phy *phy;
> - int phy_number;
> - int ret = 0;
> + int phy_num;
> + int ret;
>
> for_each_available_child_of_node(dev->of_node, child) {
> - ret = of_property_read_u32(child, "reg", &phy_number);
> + ret = of_property_read_u32(child, "reg", &phy_num);
> if (ret) {
> dev_err(dev, "Failed to parse device tree\n");
> of_node_put(child);
> return ret;
> }
>
> - if (phy_number >= PHY_NUMBER) {
> + if (phy_num >= PHY_NUMBER) {
> dev_err(dev, "Invalid number of PHYs\n");
> of_node_put(child);
> return -EINVAL;
> }
>
> - phy = devm_of_phy_get(dev, child, NULL);
> + exynos_ehci->phy[phy_num] = devm_of_phy_get(dev, child, NULL);
> + phy = exynos_ehci->phy[phy_num];
> of_node_put(child);
> - if (IS_ERR(phy))
> - /* Lets fallback to older USB-PHYs */
> - goto usb_phy_old;
> - exynos_ehci->phy_g[phy_number] = phy;
> - /* Make the older PHYs unavailable */
> - exynos_ehci->phy = ERR_PTR(-ENXIO);
> - }
> -
> - return 0;
> -
> -usb_phy_old:
> - exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> - if (IS_ERR(exynos_ehci->phy)) {
> - ret = PTR_ERR(exynos_ehci->phy);
> - if (ret != -ENXIO && ret != -ENODEV) {
> - dev_err(dev, "no usb2 phy configured\n");
> - return ret;
> + if (IS_ERR(phy)) {
> + ret = PTR_ERR(phy);
> + if (ret == -EPROBE_DEFER) {
> + return ret;
> + } else if (ret != -ENOSYS && ret != -ENODEV) {
> + dev_err(dev,
> + "Error retrieving usb2 phy: %d\n", ret);
> + return PTR_ERR(phy);
> + }
> }
> - dev_dbg(dev, "Failed to get usb2 phy\n");
> - } else {
> - exynos_ehci->otg = exynos_ehci->phy->otg;
> }
>
> - return ret;
> + return 0;
> }
>
> static int exynos_ehci_phy_enable(struct device *dev)
> @@ -111,16 +96,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
> int i;
> int ret = 0;
>
> - if (!IS_ERR(exynos_ehci->phy))
> - return usb_phy_init(exynos_ehci->phy);
> -
> for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
> - if (!IS_ERR(exynos_ehci->phy_g[i]))
> - ret = phy_power_on(exynos_ehci->phy_g[i]);
> + if (!IS_ERR(exynos_ehci->phy[i]))
> + ret = phy_power_on(exynos_ehci->phy[i]);
> if (ret)
> for (i--; i >= 0; i--)
> - if (!IS_ERR(exynos_ehci->phy_g[i]))
> - phy_power_off(exynos_ehci->phy_g[i]);
> + if (!IS_ERR(exynos_ehci->phy[i]))
> + phy_power_off(exynos_ehci->phy[i]);
>
> return ret;
> }
> @@ -131,14 +113,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
> struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
> int i;
>
> - if (!IS_ERR(exynos_ehci->phy)) {
> - usb_phy_shutdown(exynos_ehci->phy);
> - return;
> - }
> -
> for (i = 0; i < PHY_NUMBER; i++)
> - if (!IS_ERR(exynos_ehci->phy_g[i]))
> - phy_power_off(exynos_eh
Re: [PATCH v3 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support
On Wednesday, September 17, 2014 8:18 PM, Vivek Gautam wrote:
>
> Now that we have completely moved from older USB-PHY drivers
> to newer GENERIC-PHY drivers for PHYs available with USB controllers
> on Exynos series of SoCs, we can remove the support for the same
> in our host drivers too.
>
> Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/usb/host/ohci-exynos.c | 89
> +++-
> 1 file changed, 24 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> index 7c48e3f..992b28d 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -19,11 +19,8 @@
> #include
> #include
> #include
> -#include
> -#include
> #include
> #include
> -#include
>
> #include "ohci.h"
>
> @@ -38,9 +35,7 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
>
> struct exynos_ohci_hcd {
> struct clk *clk;
> - struct usb_phy *phy;
> - struct usb_otg *otg;
> - struct phy *phy_g[PHY_NUMBER];
> + struct phy *phy[PHY_NUMBER];
> };
>
> static int exynos_ohci_get_phy(struct device *dev,
> @@ -48,56 +43,40 @@ static int exynos_ohci_get_phy(struct device *dev,
> {
> struct device_node *child;
> struct phy *phy;
> - int phy_number;
> - int ret = 0;
> + int phy_num;
> + int ret;
>
> - /*
> - * Getting generic phy:
> - * We are keeping both types of phys as a part of transiting OHCI
> - * to generic phy framework, so as to maintain backward compatibilty
> - * with old DTB too.
> - * We fallback to older USB-PHYs when we fail to get generic PHYs.
> - */
> + /* Get the generic phys */
> for_each_available_child_of_node(dev->of_node, child) {
> - ret = of_property_read_u32(child, "reg", &phy_number);
> + ret = of_property_read_u32(child, "reg", &phy_num);
> if (ret) {
> dev_err(dev, "Failed to parse device tree\n");
> of_node_put(child);
> return ret;
> }
>
> - if (phy_number >= PHY_NUMBER) {
> + if (phy_num >= PHY_NUMBER) {
> dev_err(dev, "Invalid number of PHYs\n");
> of_node_put(child);
> return -EINVAL;
> }
>
> - phy = devm_of_phy_get(dev, child, NULL);
> + exynos_ohci->phy[phy_num] = devm_of_phy_get(dev, child, NULL);
> + phy = exynos_ohci->phy[phy_num];
> of_node_put(child);
> - if (IS_ERR(phy))
> - /* Lets fallback to older USB-PHYs */
> - goto usb_phy_old;
> - exynos_ohci->phy_g[phy_number] = phy;
> - /* Make the older PHYs unavailable */
> - exynos_ohci->phy = ERR_PTR(-ENXIO);
> - }
> -
> - return 0;
> -
> -usb_phy_old:
> - exynos_ohci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> - if (IS_ERR(exynos_ohci->phy)) {
> - ret = PTR_ERR(exynos_ohci->phy);
> - if (ret != -ENXIO && ret != -ENODEV) {
> - dev_err(dev, "no usb2 phy configured\n");
> - return ret;
> + if (IS_ERR(phy)) {
> + ret = PTR_ERR(phy);
> + if (ret == -EPROBE_DEFER) {
> + return ret;
> + } else if (ret != -ENOSYS && ret != -ENODEV) {
> + dev_err(dev,
> + "Error retrieving usb2 phy: %d\n", ret);
> + return PTR_ERR(phy);
> + }
> }
> - dev_dbg(dev, "Failed to get usb2 phy\n");
> - } else {
> - exynos_ohci->otg = exynos_ohci->phy->otg;
> }
>
> - return ret;
> + return 0;
> }
>
> static int exynos_ohci_phy_enable(struct device *dev)
> @@ -107,16 +86,13 @@ static int exynos_ohci_phy_enable(struct device *dev)
> int i;
> int ret = 0;
>
> - if (!IS_ERR(exynos_ohci->phy))
> - return usb_phy_init(exynos_ohci->phy);
> -
> for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
> - if (!IS_ERR(exynos_ohci->phy_g[i]))
> - ret = phy_power_on(exynos_ohci->phy_g[i]);
> + if (!IS_ERR(exynos_ohci->phy[i]))
> + ret = phy_power_on(exynos_ohci->phy[i]);
> if (ret)
> for (i--; i >= 0; i--)
> - if (!IS_ERR(exynos_ohci->phy_g[i]))
> - phy_power_off(exynos_ohci->phy_g[i]);
> + if (!IS_ERR(exynos_ohci->phy[i]))
> + phy_power_off(exynos_ohci->phy[i]);
>
> return ret;
> }
> @@ -127,14 +103,9 @@ static void exynos_ohci_phy_disable(struct device *dev)
> struct exynos_ohci_hcd *exynos_ohc
RE: [PATCH RESEND] ARM: DTS: correct the capability string for mmc0
Doug Anderson wrote: > > Vivek, > Hi, > On Tue, Sep 16, 2014 at 1:50 AM, Vivek Gautam > wrote: > > From: Naveen Krishna Chatradhi > > > > MMC capability for HS200 is parsed in mmc/core/host.c as > > dts string "mmc-hs200-1_8v". > > > > This patch corrects the dts string for Exynos5420 based peach-pit > > and Exynos5800 based peach-pi boards. > > > > Signed-off-by: Naveen Krishna Chatradhi In this case, Vivek's sign is required here. > > --- > > > > Hi Kukjin, > > > > As commented by Doug earlier for this patch, the two patches required > > -- mmc: dw_mmc: Make sure we don't get stuck when we get an error > > -- mmc: dw_mmc: change to use recommended reset procedure > > are now merged in upstream. > > So you can go ahead and pick this change. > > > > arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +- > > arch/arm/boot/dts/exynos5800-peach-pi.dts |2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > Reviewed-by: Doug Anderson Thanks, I will take this patch once Vivek replies his sign on this patch. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: DTS: correct the capability string for mmc0
Hi Kukjin, On Wed, Sep 17, 2014 at 5:39 PM, Kukjin Kim wrote: > Doug Anderson wrote: >> >> Vivek, >> > Hi, > >> On Tue, Sep 16, 2014 at 1:50 AM, Vivek Gautam >> wrote: >> > From: Naveen Krishna Chatradhi >> > >> > MMC capability for HS200 is parsed in mmc/core/host.c as >> > dts string "mmc-hs200-1_8v". >> > >> > This patch corrects the dts string for Exynos5420 based peach-pit >> > and Exynos5800 based peach-pi boards. >> > >> > Signed-off-by: Naveen Krishna Chatradhi > > In this case, Vivek's sign is required here. Ok, i will resend it with my Signed-off > >> > --- >> > >> > Hi Kukjin, >> > >> > As commented by Doug earlier for this patch, the two patches required >> > -- mmc: dw_mmc: Make sure we don't get stuck when we get an error >> > -- mmc: dw_mmc: change to use recommended reset procedure >> > are now merged in upstream. >> > So you can go ahead and pick this change. >> > >> > arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +- >> > arch/arm/boot/dts/exynos5800-peach-pi.dts |2 +- >> > 2 files changed, 2 insertions(+), 2 deletions(-) >> >> Reviewed-by: Doug Anderson > > Thanks, I will take this patch once Vivek replies his sign on this patch. > > - Kukjin > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: fix plane-framebuffer linkage
On Wed, Sep 17, 2014 at 1:44 AM, Joonyoung Shim wrote: > It's problem to add this from commit 25c8b5c3048cb6c98d402ca8d4735ccf910f727c. My patch moves that drm_framebuffer_reference() call to the plane function which is called from crtc_mode_set context (and also called in crtc pageflip path), so there should be no problem here. > Chip specific drm driver internally doesn't have to care fb reference count if > there is no special case. We should have switched to universal plane at that > time. To me it seems like the chip-specific DRM drivers do need to add a reference in the crtc_mode_set and crtc page flip paths otherwise framebuffer removal crashes (expecting to remove 3 references), as noted by my testing and also in commit 25c8b5c304. However, I'll be happy if universal planes means the driver does not have to care about this any more. Andrej, please go ahead if you are interested, I'll be happy to test your results. Thanks Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: DTS: correct the capability string for mmc0
On Wed, Sep 17, 2014 at 5:43 PM, Vivek Gautam wrote: > Hi Kukjin, > > > On Wed, Sep 17, 2014 at 5:39 PM, Kukjin Kim wrote: >> Doug Anderson wrote: >>> >>> Vivek, >>> >> Hi, >> >>> On Tue, Sep 16, 2014 at 1:50 AM, Vivek Gautam >>> wrote: >>> > From: Naveen Krishna Chatradhi >>> > >>> > MMC capability for HS200 is parsed in mmc/core/host.c as >>> > dts string "mmc-hs200-1_8v". >>> > >>> > This patch corrects the dts string for Exynos5420 based peach-pit >>> > and Exynos5800 based peach-pi boards. >>> > >>> > Signed-off-by: Naveen Krishna Chatradhi >> >> In this case, Vivek's sign is required here. > > Ok, i will resend it with my Signed-off. > >> >>> > --- >>> > >>> > Hi Kukjin, >>> > >>> > As commented by Doug earlier for this patch, the two patches required >>> > -- mmc: dw_mmc: Make sure we don't get stuck when we get an error >>> > -- mmc: dw_mmc: change to use recommended reset procedure >>> > are now merged in upstream. >>> > So you can go ahead and pick this change. >>> > >>> > arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +- >>> > arch/arm/boot/dts/exynos5800-peach-pi.dts |2 +- >>> > 2 files changed, 2 insertions(+), 2 deletions(-) >>> >>> Reviewed-by: Doug Anderson >> >> Thanks, I will take this patch once Vivek replies his sign on this patch. As suggested, giving my signed-off here: Signed-off-by: Vivek Gautam -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
On Wed, Sep 17, 2014 at 2:57 PM, Laurent Pinchart wrote: > Hi Ajay, > > On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote: >> On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote: >> > Hi Ajay, >> > >> > Thank you for the patch. >> > >> > I think we're moving in the right direction, but we're not there yet. >> > >> > On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote: >> >> This patch tries to seperate drm_bridge implementation >> >> into 2 parts, a drm part and a non_drm part. >> >> >> >> A set of helper functions are defined in this patch to make >> >> bridge driver probe independent of the drm flow. >> >> >> >> The bridge devices register themselves on a lookup table >> >> when they get probed by calling "drm_bridge_add_for_lookup". >> >> >> >> The parent encoder driver waits till the bridge is available in the >> >> lookup table(by calling "of_drm_find_bridge") and then continues with >> >> its initialization. >> > >> > Before the introduction of the component framework I would have said this >> > is the way to go. Now, I think bridges should register themselves as >> > components, and the DRM master driver should use the component framework >> > to get a reference to the bridges it needs. >> >> Well, I have modified the bridge framework exactly the way Thierry wanted it >> to be, I mean the same way the current panel framework is. >> And, I don't think there is a problem with that. >> What problem are you facing with current bridge implementation? >> What is the advantage of using the component framework to register bridges? > > There are several advantages. > > - The component framework has been designed with this exact problem in mind, > piecing multiple components into a display device. This patch set introduces > yet another framework, without any compelling reason as far as I can see. Without this bridge registration framework, there is no way you can pass on a drm_device pointer to the bridge driver. That is why we added a lookup framework. > Today DRM drivers already need to use three different frameworks (component, > I2C slave encoder and panel), and we're adding a fourth one to make the mess > even messier. This is really a headlong rush, we need to stop and fix the > design mistakes. > > - The component framework solves the probe ordering problem. Bridges can use > deferred probing, but when a bridge requires a resources (such as a clock for > instance) provided by the display controller, this will break. This is exactly the way sti drm uses bridge I think. It uses component framework to wait till the master device initializes and then passes on a drm_device pointer to the component devices. But please know that it is feasible in case of sti, because the bridge they use must be a embedded chip on the SOC, but not a third party device. And, the case which you mentioned(clock instance need to be passed to bridge driver) happens only in the case of bridges embedded on the SOC, but not a third party device. So, you are always allowed to use component framework for that. But, assume the bridge chip is a third party device(ex: ptn3460 or ps8622) which sits on an i2c bus. In that case, your approach poses the foll problems: The way master and components are binded varies from platform to platform. i.e the way exynos consolidates and adds the components is very much different the way msm/sti/armada does the same! So, when one needs to use a third party device as a bridge, they will end up hacking up their drm layer to support this third party device. With my approach, only the corresponding encoder driver needs to know about the bridge, that too just the phandle to bridge node. The platform specific drm layer can still be unaware of the bridge and stuff. With your approach, the way we would specify the bridge node will change from platform to platform resulting in non-uniformity. Also, the platform specific drm layer needs to be aware of the bridge. And, I assume these are the reasons why drm_panel doesn't use component framework. Because all the panels are often third party and hence can be reused across platforms, and so are ptn3460/ps8622. >> >> The encoder driver should call "drm_bridge_attach_encoder" to pass on >> >> the drm_device and the encoder pointers to the bridge object. >> >> >> >> Now that the drm_device pointer is available, the encoder then calls >> >> "bridge->funcs->post_encoder_init" to allow the bridge to continue >> >> registering itself with the drm core. >> > >> > This is what really bothers me with DRM bridge. >> > >> > The framework assumes that a bridge will always bridge an encoder and a >> > connector. Beside lacking support for chained bridges, this creates an >> > artificial split between bridges and encoders by modeling the same >> > components using drm_encoder or drm_bridge depending on their position in >> > the video output pipeline. >> > >> > I would like to see drm_bridge becoming more self-centric, removing the >> > awareness of the upstream
Re: [PATCH] drm/exynos: fix plane-framebuffer linkage
On Wed, Sep 17, 2014 at 2:19 PM, Daniel Drake wrote: >> Chip specific drm driver internally doesn't have to care fb reference count >> if >> there is no special case. We should have switched to universal plane at that >> time. > > To me it seems like the chip-specific DRM drivers do need to add a > reference in the crtc_mode_set and crtc page flip paths otherwise > framebuffer removal crashes (expecting to remove 3 references), as > noted by my testing and also in commit 25c8b5c304. I think fb refcounting in exynos is just plain busted. If you look at other drivers the only place the refcount framebuffers or backing storage objects is for pageflips to make sure the memory doesn't go away while the hw is still scanning out the old framebuffer. If you refcount anywhere else you either do something really crazy or your driver is broken. > However, I'll be happy if universal planes means the driver does not > have to care about this any more. Andrej, please go ahead if you are > interested, I'll be happy to test your results. universal planes will fix up the mess with 2 drm plane objects (primary plane + exonys internal primary). So should help to untangle this not, but it will not magically fix the refcounting bugs itself. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] drm/exynos: use drm generic mmap interface
This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
to Exynos drm and instead uses drm generic mmap.
We had used the interface specific to Exynos drm to do mmap directly,
not to use demand paging which maps each page with physical memory
at page fault handler. We don't need the specific mmap interface
because the drm generic mmap which uses vm offset manager stuff can
also do mmap directly.
This patch makes a userspace region to be mapped with whole physical
memory region allocated by userspace request when mmap system call is
requested.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 25 -
drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
drivers/gpu/drm/exynos/exynos_drm_gem.c | 84 ++-
drivers/gpu/drm/exynos/exynos_drm_gem.h | 10
include/uapi/drm/exynos_drm.h | 22
5 files changed, 14 insertions(+), 128 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 10ad3d4..a7819eb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -149,10 +149,6 @@ static int exynos_drm_unload(struct drm_device *dev)
return 0;
}
-static const struct file_operations exynos_drm_gem_fops = {
- .mmap = exynos_drm_gem_mmap_buffer,
-};
-
static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
{
struct drm_connector *connector;
@@ -191,7 +187,6 @@ static int exynos_drm_resume(struct drm_device *dev)
static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
{
struct drm_exynos_file_private *file_priv;
- struct file *anon_filp;
int ret;
file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
@@ -204,21 +199,8 @@ static int exynos_drm_open(struct drm_device *dev, struct
drm_file *file)
if (ret)
goto err_file_priv_free;
- anon_filp = anon_inode_getfile("exynos_gem", &exynos_drm_gem_fops,
- NULL, 0);
- if (IS_ERR(anon_filp)) {
- ret = PTR_ERR(anon_filp);
- goto err_subdrv_close;
- }
-
- anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
- file_priv->anon_filp = anon_filp;
-
return ret;
-err_subdrv_close:
- exynos_drm_subdrv_close(dev, file);
-
err_file_priv_free:
kfree(file_priv);
file->driver_priv = NULL;
@@ -234,7 +216,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
{
struct exynos_drm_private *private = dev->dev_private;
- struct drm_exynos_file_private *file_priv;
struct drm_pending_vblank_event *v, *vt;
struct drm_pending_event *e, *et;
unsigned long flags;
@@ -260,10 +241,6 @@ static void exynos_drm_postclose(struct drm_device *dev,
struct drm_file *file)
}
spin_unlock_irqrestore(&dev->event_lock, flags);
- file_priv = file->driver_priv;
- if (file_priv->anon_filp)
- fput(file_priv->anon_filp);
-
kfree(file->driver_priv);
file->driver_priv = NULL;
}
@@ -282,8 +259,6 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
- exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 69a6fa3..d22e640 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -240,7 +240,6 @@ struct exynos_drm_g2d_private {
struct drm_exynos_file_private {
struct exynos_drm_g2d_private *g2d_priv;
struct device *ipp_dev;
- struct file *anon_filp;
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 2f3665d..3cf6494 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -318,21 +318,17 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
}
-int exynos_drm_gem_mmap_buffer(struct file *filp,
+int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj *exynos_gem_obj,
struct vm_area_struct *vma)
{
- struct drm_gem_object *obj = filp->private_data;
- struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
- struct drm_device *drm_dev = obj->dev;
+ struct drm_device *drm_dev
[PATCH 0/2] drm/exynos: use drm generic mmap interface
This patch set removes unnecessary DRM_EXYNOS_GEM_MAP_OFFSET interface which isn't used anymore and also uses drm generic mmap interface instead of a mmap interface specific to Exynos drm. So this patch set removes a existing mmap interface and relevant codes specific to Exynos drm. Inki Dae (2): drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl drm/exynos: use drm generic mmap interface drivers/gpu/drm/exynos/exynos_drm_drv.c | 28 - drivers/gpu/drm/exynos/exynos_drm_drv.h |1 - drivers/gpu/drm/exynos/exynos_drm_gem.c | 101 +-- drivers/gpu/drm/exynos/exynos_drm_gem.h | 14 - include/uapi/drm/exynos_drm.h | 40 5 files changed, 14 insertions(+), 170 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl
This interface and relevant codes aren't used anymore.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |3 ---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 17 -
drivers/gpu/drm/exynos/exynos_drm_gem.h |4
include/uapi/drm/exynos_drm.h | 18 --
4 files changed, 42 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 9b00e4e..10ad3d4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -282,9 +282,6 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP_OFFSET,
- exynos_drm_gem_map_offset_ioctl, DRM_UNLOCKED |
- DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 15db801..2f3665d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -318,23 +318,6 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
}
-int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
-{
- struct drm_exynos_gem_map_off *args = data;
-
- DRM_DEBUG_KMS("handle = 0x%x, offset = 0x%lx\n",
- args->handle, (unsigned long)args->offset);
-
- if (!(dev->driver->driver_features & DRIVER_GEM)) {
- DRM_ERROR("does not support GEM.\n");
- return -ENODEV;
- }
-
- return exynos_drm_gem_dumb_map_offset(file_priv, dev, args->handle,
- &args->offset);
-}
-
int exynos_drm_gem_mmap_buffer(struct file *filp,
struct vm_area_struct *vma)
{
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 1592c0b..8e46094 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -111,10 +111,6 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
unsigned int gem_handle,
struct drm_file *filp);
-/* get buffer offset to map to user space. */
-int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-
/*
* mmap the physically continuous memory that a gem object contains
* to user space.
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index d584412..67a751c 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -33,20 +33,6 @@ struct drm_exynos_gem_create {
};
/**
- * A structure for getting buffer offset.
- *
- * @handle: a pointer to gem object created.
- * @pad: just padding to be 64-bit aligned.
- * @offset: relatived offset value of the memory region allocated.
- * - this value should be set by user.
- */
-struct drm_exynos_gem_map_off {
- unsigned int handle;
- unsigned int pad;
- uint64_t offset;
-};
-
-/**
* A structure for mapping buffer.
*
* @handle: a handle to gem object created.
@@ -316,7 +302,6 @@ struct drm_exynos_ipp_cmd_ctrl {
};
#define DRM_EXYNOS_GEM_CREATE 0x00
-#define DRM_EXYNOS_GEM_MAP_OFFSET 0x01
#define DRM_EXYNOS_GEM_MMAP0x02
/* Reserved 0x03 ~ 0x05 for exynos specific gem ioctl */
#define DRM_EXYNOS_GEM_GET 0x04
@@ -336,9 +321,6 @@ struct drm_exynos_ipp_cmd_ctrl {
#define DRM_IOCTL_EXYNOS_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
-#define DRM_IOCTL_EXYNOS_GEM_MAP_OFFSETDRM_IOWR(DRM_COMMAND_BASE + \
- DRM_EXYNOS_GEM_MAP_OFFSET, struct drm_exynos_gem_map_off)
-
#define DRM_IOCTL_EXYNOS_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_MMAP, struct drm_exynos_gem_mmap)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
Hi Tomi,
Thanks for your comments.
On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen wrote:
> On 27/08/14 17:39, Ajay Kumar wrote:
>> Add documentation for DT properties supported by ps8622/ps8625
>> eDP-LVDS converter.
>>
>> Signed-off-by: Ajay Kumar
>> ---
>> .../devicetree/bindings/video/bridge/ps8622.txt| 20
>>
>> 1 file changed, 20 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
>>
>> diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
>> b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
>> new file mode 100644
>> index 000..0ec8172
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
>> @@ -0,0 +1,20 @@
>> +ps8622-bridge bindings
>> +
>> +Required properties:
>> + - compatible: "parade,ps8622" or "parade,ps8625"
>> + - reg: first i2c address of the bridge
>> + - sleep-gpios: OF device-tree gpio specification for PD_ pin.
>> + - reset-gpios: OF device-tree gpio specification for RST_ pin.
>> +
>> +Optional properties:
>> + - lane-count: number of DP lanes to use
>> + - use-external-pwm: backlight will be controlled by an external PWM
>
> What does this mean? That the backlight support from ps8625 is not used?
> If so, maybe "disable-pwm" or something?
"use-external-pwm" or "disable-bridge-pwm" would be better.
>> +
>> +Example:
>> + lvds-bridge@48 {
>> + compatible = "parade,ps8622";
>> + reg = <0x48>;
>> + sleep-gpios = <&gpc3 6 1 0 0>;
>> + reset-gpios = <&gpc3 1 1 0 0>;
>> + lane-count = <1>;
>> + };
>>
>
> I wish all new display component bindings would use the video
> ports/endpoints to describe the connections. It will be very difficult
> to improve the display driver model later if we're missing such critical
> pieces from the DT bindings.
Why do we need a complex graph when it can be handled using a simple phandle?
Ajay
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
On Wed, 17 Sep 2014, Vivek Gautam wrote:
> Now that we have completely moved from older USB-PHY drivers
> to newer GENERIC-PHY drivers for PHYs available with USB controllers
> on Exynos series of SoCs, we can remove the support for the same
> in our host drivers too.
>
> Signed-off-by: Vivek Gautam
I don't see why you made your changes in this awkward way. For
instance...
> @@ -59,49 +54,39 @@ static int exynos_ehci_get_phy(struct device *dev,
> {
> struct device_node *child;
> struct phy *phy;
> - int phy_number;
> - int ret = 0;
> + int phy_num;
Why rename this variable? Wasn't the original name good enough?
> + int ret;
>
> for_each_available_child_of_node(dev->of_node, child) {
> - ret = of_property_read_u32(child, "reg", &phy_number);
> + ret = of_property_read_u32(child, "reg", &phy_num);
> if (ret) {
> dev_err(dev, "Failed to parse device tree\n");
> of_node_put(child);
> return ret;
> }
>
> - if (phy_number >= PHY_NUMBER) {
> + if (phy_num >= PHY_NUMBER) {
> dev_err(dev, "Invalid number of PHYs\n");
> of_node_put(child);
> return -EINVAL;
> }
>
> - phy = devm_of_phy_get(dev, child, NULL);
> + exynos_ehci->phy[phy_num] = devm_of_phy_get(dev, child, NULL);
> + phy = exynos_ehci->phy[phy_num];
Why make two changes, resulting in more code, when you could have made
just one change?
phy = devm_of_phy_get(dev, child, NULL);
+ exynos_ehci->phy[phy_num] = phy;
Also, the patch description should mention that you are adding support
for EPROBE_DEFER.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] drm/exynos: use drm generic mmap interface
On Wed, Sep 17, 2014 at 10:48:44PM +0900, Inki Dae wrote: > This patch set removes unnecessary DRM_EXYNOS_GEM_MAP_OFFSET interface > which isn't used anymore and also uses drm generic mmap interface > instead of a mmap interface specific to Exynos drm. So this patch set > removes a existing mmap interface and relevant codes specific to Exynos > drm. > > Inki Dae (2): > drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl > drm/exynos: use drm generic mmap interface Thanks for doing this. Acked-by: Daniel Vetter -Daniel > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 28 - > drivers/gpu/drm/exynos/exynos_drm_drv.h |1 - > drivers/gpu/drm/exynos/exynos_drm_gem.c | 101 > +-- > drivers/gpu/drm/exynos/exynos_drm_gem.h | 14 - > include/uapi/drm/exynos_drm.h | 40 > 5 files changed, 14 insertions(+), 170 deletions(-) > > -- > 1.7.9.5 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices
On Wednesday 17 September 2014, Pankaj Dubey wrote: > --- > V2 of this patchset and related discussion can be found here [1]. > > Changes since v2: > - Added back platform device support from syscon, with one change that >syscon will not be probed for DT based platform. > - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base >users of syscon will not be broken. > - Removed unwanted change in syscon.h. > - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and >Arnd Bergmann. > - Added Tested-by of Vivek Gautam for testing on Exynos platform. Looks fine. Provided you can figure out the problem that Dong Aisheng reported, please add my Acked-by: Arnd Bergmann > -} > +static struct syscon *of_syscon_register(struct device_node *np); > One minor comment: please avoid doing forward declarations of local functions. It took me a while to understand what is going on because I expect all functions to be ordered such that they only get called by functions below, and don't need this. Just move of_syscon_register() here directly. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: Add rtc_src clk for s3c-rtc on exynos Peach boards
Javier,
On Wed, Sep 17, 2014 at 4:50 AM, Javier Martinez Canillas
wrote:
> commit 546b117fdf17 ("rtc: s3c: add support for RTC of Exynos3250 SoC")
> added an "rtc_src" DT property for the Samsung's S3C Real Time Clock
> controller that specifies the 32.768 kHz clock that uses the RTC as its
> source clock. In the case of the Peach Pit and Pi machines, the Maxim
> 77802 32kHz AP clock is used as the source clock.
>
> Signed-off-by: Javier Martinez Canillas
> ---
> arch/arm/boot/dts/exynos5420-peach-pit.dts | 5 -
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 -
> 2 files changed, 8 insertions(+), 2 deletions(-)
Reviewed-by: Doug Anderson
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow
Hi,
On Wed, Sep 17, 2014 at 4:50 AM, Javier Martinez Canillas
wrote:
> commit 546b117fdf17 ("rtc: s3c: add support for RTC of Exynos3250 SoC")
> added an "rtc_src" DT property for the Samsung's S3C Real Time Clock
> controller that specifies the 32.768 kHz clock that uses the RTC as its
> source clock. In the case of the Exynos5250 based Snow board, the Maxim
> 77686 32kHz AP clock is used as the source clock.
>
> Signed-off-by: Javier Martinez Canillas
> ---
> arch/arm/boot/dts/exynos5250-snow.dts | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index e51fcef..56eec56 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -10,6 +10,7 @@
>
> /dts-v1/;
> #include
> +#include
> #include "exynos5250.dtsi"
>
> / {
> @@ -29,6 +30,8 @@
>
> rtc@101E {
> status = "okay";
> + clocks = <&clock CLK_RTC>, <&max77686 MAX77686_CLK_AP>;
> + clock-names = "rtc", "rtc_src";
Wait, seriously? Snow is still using the "rtc@101E" syntax?
Whatever happened to the series that Andreas worked so hard on,
including
Re: [PATCH 2/2] ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow
Am 17.09.2014 um 17:47 schrieb Doug Anderson:
> Hi,
>
> On Wed, Sep 17, 2014 at 4:50 AM, Javier Martinez Canillas
> wrote:
>> commit 546b117fdf17 ("rtc: s3c: add support for RTC of Exynos3250 SoC")
>> added an "rtc_src" DT property for the Samsung's S3C Real Time Clock
>> controller that specifies the 32.768 kHz clock that uses the RTC as its
>> source clock. In the case of the Exynos5250 based Snow board, the Maxim
>> 77686 32kHz AP clock is used as the source clock.
>>
>> Signed-off-by: Javier Martinez Canillas
>> ---
>> arch/arm/boot/dts/exynos5250-snow.dts | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
>> b/arch/arm/boot/dts/exynos5250-snow.dts
>> index e51fcef..56eec56 100644
>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>> @@ -10,6 +10,7 @@
>>
>> /dts-v1/;
>> #include
>> +#include
>> #include "exynos5250.dtsi"
>>
>> / {
>> @@ -29,6 +30,8 @@
>>
>> rtc@101E {
>> status = "okay";
>> + clocks = <&clock CLK_RTC>, <&max77686 MAX77686_CLK_AP>;
>> + clock-names = "rtc", "rtc_src";
>
> Wait, seriously? Snow is still using the "rtc@101E" syntax?
> Whatever happened to the series that Andreas worked so hard on,
> including
Re: [PATCH 7/9] phy: remove .owner field for drivers using module_platform_driver
Hi, On Friday 15 August 2014 06:10 PM, Peter Griffin wrote: > This patch removes the superflous .owner field for drivers which > use the module_platform_driver or platform_driver_register api, > as this is overriden in __platform_driver_register. > > Signed-off-by: Peter Griffin > --- > drivers/phy/phy-bcm-kona-usb2.c | 1 - > drivers/phy/phy-berlin-sata.c | 1 - > drivers/phy/phy-exynos-dp-video.c | 1 - > drivers/phy/phy-exynos-mipi-video.c | 1 - > drivers/phy/phy-exynos5-usbdrd.c| 1 - > drivers/phy/phy-exynos5250-sata.c | 1 - > drivers/phy/phy-hix5hd2-sata.c | 1 - > drivers/phy/phy-miphy365x.c | 1 - > drivers/phy/phy-mvebu-sata.c| 1 - > drivers/phy/phy-omap-control.c | 1 - > drivers/phy/phy-omap-usb2.c | 1 - > drivers/phy/phy-qcom-apq8064-sata.c | 1 - > drivers/phy/phy-qcom-ipq806x-sata.c | 1 - > drivers/phy/phy-samsung-usb2.c | 1 - > drivers/phy/phy-sun4i-usb.c | 1 - > drivers/phy/phy-ti-pipe3.c | 1 - > drivers/phy/phy-twl4030-usb.c | 1 - twl4030-usb doesn't use module_platform_driver. Care to resend this patch along? I've merged all other patches in this series. Cheers Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On 17/09/14 17:29, Ajay kumar wrote:
> Hi Tomi,
>
> Thanks for your comments.
>
> On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen wrote:
>> On 27/08/14 17:39, Ajay Kumar wrote:
>>> Add documentation for DT properties supported by ps8622/ps8625
>>> eDP-LVDS converter.
>>>
>>> Signed-off-by: Ajay Kumar
>>> ---
>>> .../devicetree/bindings/video/bridge/ps8622.txt| 20
>>>
>>> 1 file changed, 20 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/video/bridge/ps8622.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
>>> b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
>>> new file mode 100644
>>> index 000..0ec8172
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
>>> @@ -0,0 +1,20 @@
>>> +ps8622-bridge bindings
>>> +
>>> +Required properties:
>>> + - compatible: "parade,ps8622" or "parade,ps8625"
>>> + - reg: first i2c address of the bridge
>>> + - sleep-gpios: OF device-tree gpio specification for PD_ pin.
>>> + - reset-gpios: OF device-tree gpio specification for RST_ pin.
>>> +
>>> +Optional properties:
>>> + - lane-count: number of DP lanes to use
>>> + - use-external-pwm: backlight will be controlled by an external PWM
>>
>> What does this mean? That the backlight support from ps8625 is not used?
>> If so, maybe "disable-pwm" or something?
> "use-external-pwm" or "disable-bridge-pwm" would be better.
Well, the properties are about the bridge. "use-external-pwm" means that
the bridge uses an external PWM, which, if I understood correctly, is
not what the property is about.
"disable-bridge-pwm" is ok, but the "bridge" there is extra. The
properties are about the bridge, so it's implicit.
>>> +
>>> +Example:
>>> + lvds-bridge@48 {
>>> + compatible = "parade,ps8622";
>>> + reg = <0x48>;
>>> + sleep-gpios = <&gpc3 6 1 0 0>;
>>> + reset-gpios = <&gpc3 1 1 0 0>;
>>> + lane-count = <1>;
>>> + };
>>>
>>
>> I wish all new display component bindings would use the video
>> ports/endpoints to describe the connections. It will be very difficult
>> to improve the display driver model later if we're missing such critical
>> pieces from the DT bindings.
> Why do we need a complex graph when it can be handled using a simple phandle?
Maybe in your case you can handle it with simple phandle. Can you
guarantee that it's enough for everyone, on all platforms?
The point of the ports/endpoint graph is to also support more
complicated scenarios. If you now create ps8622 bindings that do not
support those graphs, the no one else using ps8622 can use
ports/endpoint graphs either.
Btw, is there an example how the bridge with these bindings is used in a
board's .dts file? I couldn't find any example with a quick search. So
it's unclear to me what the "simple phandle" actually is.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v3 5/6] mfd: cros_ec: wait for completion of commands that return IN_PROGRESS
On Thu, 11 Sep 2014, Javier Martinez Canillas wrote:
> From: Andrew Bresticker
>
> When an EC command returns EC_RES_IN_PROGRESS, we need to query
> the state of the EC until it indicates that it is no longer busy.
> Do this in cros_ec_cmd_xfer() under the EC's mutex so that other
> commands (e.g. keyboard, I2C passtru) aren't issued to the EC while
> it is working on the in-progress command.
>
> The delay in milliseconds and the number of retries are the values
> that were used by the flashrom tool when retrying commands.
>
> Signed-off-by: Andrew Bresticker
> Reviewed-by: Simon Glass
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Changes since v2:
> - Explain in the commit message from where the delay and retry values come
> from.
>Commented by Andrew Bresticker.
> - Move the needed definitions inside the if block. Suggested by Lee Jones.
> - Only check if result is EC_RES_IN_PROGRESS instead of checking also if ret
> is
>-EAGAIN since the former implies the later. Suggested by Lee Jones.
> - Use usleep_range() instead of msleep() since doesn't handle values between
> 1~20.
>Suggested by Lee Jones.
>
> Changes since v1:
> - The *xfer() calls don't modify the passed cros_ec_command so there is
>no need to populate it inside the for loop. Suggested by Lee Jones.
>
> drivers/mfd/cros_ec.c | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index c53804a..af2fadf 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -23,6 +23,10 @@
> #include
> #include
> #include
> +#include
> +
> +#define EC_COMMAND_RETRIES 50
> +#define EC_RETRY_DELAY_MS10
>
> int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
> struct cros_ec_command *msg)
> @@ -69,6 +73,36 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
>
> mutex_lock(&ec_dev->lock);
> ret = ec_dev->cmd_xfer(ec_dev, msg);
> + if (msg->result == EC_RES_IN_PROGRESS) {
> + int i;
> + struct cros_ec_command status_msg;
> + struct ec_response_get_comms_status status;
> +
> + status_msg.version = 0;
> + status_msg.command = EC_CMD_GET_COMMS_STATUS;
> + status_msg.outdata = NULL;
> + status_msg.outsize = 0;
> + status_msg.indata = (uint8_t *)&status;
> + status_msg.insize = sizeof(status);
> +
> + /*
> + * Query the EC's status until it's no longer busy or
> + * we encounter an error.
> + */
> + for (i = 0; i < EC_COMMAND_RETRIES; i++) {
> + usleep_range(EC_RETRY_DELAY_MS, EC_RETRY_DELAY_MS + 1);
Remove the EC_RETRY_DELAY_MS define and place the values in raw.
You're now sleeping for 10us. Did you test the changes?
> + ret = ec_dev->cmd_xfer(ec_dev, &status_msg);
> + if (ret < 0)
> + break;
> +
> + msg->result = status_msg.result;
> + if (status_msg.result != EC_RES_SUCCESS)
> + break;
> + if (!(status.flags & EC_COMMS_STATUS_PROCESSING))
> + break;
> + }
> + }
> mutex_unlock(&ec_dev->lock);
>
> return ret;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/6] mfd: cros_ec: Instantiate sub-devices from device tree
On Thu, 11 Sep 2014, Javier Martinez Canillas wrote:
> From: Todd Broch
>
> If the EC device tree node has sub-nodes, try to instantiate them as
> MFD sub-devices. We can configure the EC features provided by the board.
>
> Signed-off-by: Todd Broch
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Changes since v2:
> - Drop if guards since of_node is unconditionally built. Suggested by Lee
> Jones
> - Drop unneeded comment about of_platform_populate(). Suggested by Lee Jones.
> - Fix error message if of_platform_populate() fails. Suggested by Lee Jones.
>
> Changes since v1:
> - Don't leave an empty struct mfd_cell array. Suggested by Lee Jones.
> - Just use of_platform_populate() instead of manually iterating through
>sub-devices and calling mfd_add_devices. Suggested by Lee Jones.
> ---
> drivers/mfd/cros_ec.c | 27 ---
> 1 file changed, 8 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index 751af0b..7c533d2 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -109,22 +110,10 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
> }
> EXPORT_SYMBOL(cros_ec_cmd_xfer);
>
> -static const struct mfd_cell cros_devs[] = {
> - {
> - .name = "cros-ec-keyb",
> - .id = 1,
> - .of_compatible = "google,cros-ec-keyb",
> - },
> - {
> - .name = "cros-ec-i2c-tunnel",
> - .id = 2,
> - .of_compatible = "google,cros-ec-i2c-tunnel",
> - },
> -};
> -
> int cros_ec_register(struct cros_ec_device *ec_dev)
> {
> struct device *dev = ec_dev->dev;
> + struct device_node *node = dev->of_node;
> int err = 0;
>
> if (ec_dev->din_size) {
> @@ -140,12 +129,12 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
>
> mutex_init(&ec_dev->lock);
>
> - err = mfd_add_devices(dev, 0, cros_devs,
> - ARRAY_SIZE(cros_devs),
> - NULL, ec_dev->irq, NULL);
> - if (err) {
> - dev_err(dev, "failed to add mfd devices\n");
> - return err;
So these devices will only ever probe with DT now ...
> + if (node) {
So it would be wrong for dev->of_node not to be populated.
> + err = of_platform_populate(node, NULL, NULL, dev);
> + if (err) {
> + dev_err(dev, "Failed to register subordinate devices");
> + return err;
> + }
> }
>
> dev_info(dev, "Chrome EC device registered\n");
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: fix plane-framebuffer linkage
On Wed, Sep 17, 2014 at 7:45 AM, Daniel Vetter wrote: > I think fb refcounting in exynos is just plain busted. If you look at > other drivers the only place the refcount framebuffers or backing > storage objects is for pageflips to make sure the memory doesn't go > away while the hw is still scanning out the old framebuffer. If you > refcount anywhere else you either do something really crazy or your > driver is broken. With my patch actually the behaviour is much more similar to omapdrm, which also doesn't quite match your description of "other drivers". See omap_plane.c. There is a fb reference taken for "pinning" in update_pin() which presumably is what you describe - avoid destroying the fb while it is being scanned out. (Maybe exynos should have something equivalent too, but thats a separate issue) However there is *another* fb reference taken in omap_plane_mode_set(). And my patch is modelled to do the same in exynos-drm. I believe this is necessary under the current model. At least, when drm_mode_rmfb() is running for the last user of the active framebuffer, it expects to drop 3 references from the framebuffer before dropping the 4th causes the object to be destroyed, as follows: 1. drm_mode_rmfb explicitly drops a reference - it calls __drm_framebuffer_unregister which then calls __drm_framebuffer_unreference /* Mark fb as reaped, we still have a ref from fpriv->fbs. */ __drm_framebuffer_unregister(dev, fb); 2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls drm_mode_set_config_internal() in order to turn off the CRTC, dropping another reference in the process. if (tmp->old_fb) drm_framebuffer_unreference(tmp->old_fb); 3. drm_framebuffer_remove calls drm_plane_force_disable() which drops another reference: /* disconnect the plane from the fb and crtc: */ __drm_framebuffer_unreference(old_fb); 4. drm_framebuffer drops the final reference itself, to cause freeing of the object: drm_framebuffer_unreference(fb); So ordinarily, after a fb is created by drm core (with refcnt at 1), there would have to be 3 references added to it by the time it is the primary fb so that when we do rmfb, it has a refcnt of 4, and gets freed correctly. (The second bug I was seeing with pageflips was that refcnt was 3, which means that the final reference was dropped in (3) above, but __drm_framebuffer_unreference doesn't like that at all - it calls drm_framebuffer_free_bug) Not being overly familiar with DRM internals I tried to go backwards to find out where these 3 references would be created during normal operation. 2 are clear: 1. drm_framebuffer_init() explicitly grabs one: /* Grab the idr reference. */ drm_framebuffer_reference(fb) 2. drm_mode_set_config_internal() takes one: if (tmp->primary->fb) drm_framebuffer_reference(tmp->primary->fb); Where should the 3rd one be created? I don't know, but looking at previous exynos commit 25c8b5c304 and omapdrm, I assumed that the drm driver should take one, both on crtc mode set and crtc page flip. >> However, I'll be happy if universal planes means the driver does not >> have to care about this any more. Andrej, please go ahead if you are >> interested, I'll be happy to test your results. > > universal planes will fix up the mess with 2 drm plane objects > (primary plane + exonys internal primary). So should help to untangle > this not, but it will not magically fix the refcounting bugs itself. So even when we move to universal planes (fixing 1 of the issues), its good that we're having this refcount discussion (which we need to understand to confidently solve the 2nd issue). Thanks for your input! Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC
On Tue, Sep 16, 2014 at 4:15 PM, Doug Anderson wrote: > NOTE: I don't think that the builtin RTC is terribly important for any > exynos-based Chromebooks that I'm aware of. We rely on the RTC that's > part of the Maxim PMIC itself and pretty much ignore the one built-in > to the exynos. I think there are some cases it was used (as a > fallback wakeup source in certain test scripts), but nothing very > important. That's not true for all hardware though, at least the board I'm working on now has the SoC RTC as battery-backed and the PMIC one with no battery. So in this case at least, the interesting RTC is the SoC one. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC
Daniel, On Wed, Sep 17, 2014 at 9:49 AM, Daniel Drake wrote: > On Tue, Sep 16, 2014 at 4:15 PM, Doug Anderson wrote: >> NOTE: I don't think that the builtin RTC is terribly important for any >> exynos-based Chromebooks that I'm aware of. We rely on the RTC that's >> part of the Maxim PMIC itself and pretty much ignore the one built-in >> to the exynos. I think there are some cases it was used (as a >> fallback wakeup source in certain test scripts), but nothing very >> important. > > That's not true for all hardware though, at least the board I'm > working on now has the SoC RTC as battery-backed and the PMIC one with > no battery. So in this case at least, the interesting RTC is the SoC > one. Yup, I can totally believe that. My statement was meant only to apply to the boards I knew about firsthand... -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] phy: exynos-dp-video: Use syscon support to control pmu register
On Tuesday 16 September 2014 10:32 AM, Vivek Gautam wrote:
> Currently the DP_PHY_ENABLE register is mapped in the driver,
> and accessed to control power to the PHY.
> With mfd-syscon and regmap interface available at our disposal,
> it's wise to use that instead of using a 'reg' property for the
> controller and allocating a memory resource for that.
>
> To facilitate this, we have added another compatible string
> for Exynso5420 SoC to acquire driver data which contains
> different DP-PHY-CONTROL register offset.
>
> Signed-off-by: Vivek Gautam
> Cc: Jingoo Han
> Cc: Kishon Vijay Abraham I
Taking this in linux-phy tree. If someone has already taken this patch, please
let me know.
Thanks
Kishon
> ---
>
> Changes since v2:
> - Using 'EXYNOS5_PHY_ENABLE' macro instead of 'EXYNOS_DPTX_PHY_ENABLE'
>since that's available with us in "linux/mfd/syscon/exynos5-pmu.h" file.
>
> Changes since v1:
> - state->regs should have been "struct regmap *" instead of
>"void __iomem *". So corrected the same.
>
> .../devicetree/bindings/phy/samsung-phy.txt|7 +-
> drivers/phy/phy-exynos-dp-video.c | 79
> +---
> 2 files changed, 59 insertions(+), 27 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index 7a6feea..15e0f2c 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
> -
>
> Required properties:
> -- compatible : should be "samsung,exynos5250-dp-video-phy";
> -- reg : offset and length of the Display Port PHY register set;
> +- compatible : should be one of the following supported values:
> + - "samsung,exynos5250-dp-video-phy"
> + - "samsung,exynos5420-dp-video-phy"
> +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
> + control pmu registers for power isolation.
> - #phy-cells : from the generic PHY bindings, must be 0;
>
> Samsung S5P/EXYNOS SoC series USB PHY
> diff --git a/drivers/phy/phy-exynos-dp-video.c
> b/drivers/phy/phy-exynos-dp-video.c
> index 8b3026e..53f44a0 100644
> --- a/drivers/phy/phy-exynos-dp-video.c
> +++ b/drivers/phy/phy-exynos-dp-video.c
> @@ -13,44 +13,55 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> #include
> +#include
>
> -/* DPTX_PHY_CONTROL register */
> -#define EXYNOS_DPTX_PHY_ENABLE (1 << 0)
> +struct exynos_dp_video_phy_drvdata {
> + u32 phy_ctrl_offset;
> +};
>
> struct exynos_dp_video_phy {
> - void __iomem *regs;
> + struct regmap *regs;
> + const struct exynos_dp_video_phy_drvdata *drvdata;
> };
>
> -static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int
> on)
> +static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
> + unsigned int on)
> {
> - u32 reg;
> + unsigned int val;
> +
> + if (IS_ERR(state->regs))
> + return;
>
> - reg = readl(state->regs);
> - if (on)
> - reg |= EXYNOS_DPTX_PHY_ENABLE;
> - else
> - reg &= ~EXYNOS_DPTX_PHY_ENABLE;
> - writel(reg, state->regs);
> + val = on ? 0 : EXYNOS5_PHY_ENABLE;
>
> - return 0;
> + regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
> +EXYNOS5_PHY_ENABLE, val);
> }
>
> static int exynos_dp_video_phy_power_on(struct phy *phy)
> {
> struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>
> - return __set_phy_state(state, 1);
> + /* Disable power isolation on DP-PHY */
> + exynos_dp_video_phy_pwr_isol(state, 0);
> +
> + return 0;
> }
>
> static int exynos_dp_video_phy_power_off(struct phy *phy)
> {
> struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>
> - return __set_phy_state(state, 0);
> + /* Enable power isolation on DP-PHY */
> + exynos_dp_video_phy_pwr_isol(state, 1);
> +
> + return 0;
> }
>
> static struct phy_ops exynos_dp_video_phy_ops = {
> @@ -59,11 +70,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
> .owner = THIS_MODULE,
> };
>
> +static const struct exynos_dp_video_phy_drvdata exynos5250_dp_video_phy = {
> + .phy_ctrl_offset= EXYNOS5_DPTX_PHY_CONTROL,
> +};
> +
> +static const struct exynos_dp_video_phy_drvdata exynos5420_dp_video_phy = {
> + .phy_ctrl_offset= EXYNOS5420_DPTX_PHY_CONTROL,
> +};
> +
> +static const struct of_device_id exynos_dp_video_phy_of_match[] = {
> + {
> + .compatible = "samsung,exynos5250-dp-video-phy",
> + .data = &exynos5250_dp_video_phy,
> + }, {
> + .compatible = "samsung,exynos5420-dp-video-phy",
> +
Re: [PATCH 7/9] phy: remove .owner field for drivers using module_platform_driver
Hi Kishon, On Wed, 17 Sep 2014, Kishon Vijay Abraham I wrote: > Hi, > > On Friday 15 August 2014 06:10 PM, Peter Griffin wrote: > > This patch removes the superflous .owner field for drivers which > > use the module_platform_driver or platform_driver_register api, > > as this is overriden in __platform_driver_register. > > > > Signed-off-by: Peter Griffin > > drivers/phy/phy-twl4030-usb.c | 1 - > > twl4030-usb doesn't use module_platform_driver. Care to resend this patch > along? I've merged all other patches in this series. That is true, but it does use platform_driver_register whih overrides .owner. So the patch is stil good I think (fyi see include/linux/platform_device.h). regards, Peter. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pwm-samsung: incorrect register values for 100% duty cycle
Hi, I'm using pwm-samsung on Exynos4412 for a variable-brightness LED. When the LED is set to maximum brightness via the pwm-leds driver, we arrive at pwm_samsung_config with duty_ns = period_ns, i.e. 100% duty cycle. This function does: /* -1UL will give 100% duty. */ --tcmp; writel(tcmp, our_chip->base + REG_TCMPB(pwm->hwpwm)); I think that comment is incorrect. If tcmp is written as -1UL then the LED totally turns off. And there is nothing in the Exynos4412 manual to suggest that -1UL should be set in the TCMP register for 100% duty. If I remove that --tcmp line, so that 100% duty cycle is handled as tcmp=0, the problem is solved: the LED turns on at max brightness when the leds subsystem requests so. Any ideas? Is this -1UL thing a quirk from older chip versions not applicable to Exynos4? Thanks Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exynos5420/arndale-octa: imprecise external aborts on exynos_defconfig
Thomas Abraham writes: > On Thu, Sep 11, 2014 at 12:16 AM, Kevin Hilman wrote: >> Tyler Baker writes: >> >>> Exynos5420-based Arndale octa boards have recently started failing boot >>> tests due to imprecise external aborts. This only appears to happen >>> when using exynos_defconfig and boots fine with multi_v7_defconfig. The >>> issue seems to be intermittent, so is not reliably reproducable and >>> difficult to bisect. Here are a few boot logs from recent >>> mainline/linux-next kernels that are failing: >> >> FYI, I'm seeing the same periodic aborts. For example, here's my boot >> of next-20140910: >> http://images.armcloud.us/kernel-ci/next/next-20140910/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html >> >> However, my userspace is much simpler and doesn't seem to cause a panic, >> so my boot tests report passing. (I should fixup my scripts so these >> imprecise aborts are reported as a FAIL.) >> >> I'm glad you pointed out that it happens only with exynos_defconfig and >> not multi_v7_defconfig because I noticed that too. I haven't had the >> time to track it any further than that, so maybe the exynos folks can >> help track it down from here. >> >> Thanks for reporting this, >> >> Kevin > > Hi Tyler, Kevin, > > From the bootlog you have shared, > > [1.060016] CPU4: failed to come online > [2.070031] CPU5: failed to come online > [3.080049] CPU6: failed to come online > [4.090066] CPU7: failed to come online > [4.090099] Brought up 4 CPUs > [4.090109] SMP: Total of 4 processors activated. > [4.090119] CPU: WARNING: CPU(s) started in wrong/inconsistent > modes (primary CPU mode 0x13) > [4.090128] CPU: This may indicate a broken bootloader or firmware. > > Would it be possible to set max cpus to 1, disable switcher and try > again. I don't have a arndale octa board but I have tested mainline > kernel with smdk5420 board. It boots all eight CPUs, switcher works > fine and there are no imprecise aborts seen. Sorry for the delay, I'm travelling this week. FWIW, the same CPU boot failures you hilight above are happening on multi_v7_defconfig[1] which is not getting the imprecise abort. This is only happening on exynos_defconfig[2], so I'm curious why you think the switcher or NR_CPUS might be the issues. Anyways, I narrowed this down a bit and discovered it's CONFIG_EXYNOS5420_MCPM=y that's the root cause. If I use exynos_defconfig and then disable that option, I don't get any more imprecise aborts. Kevin [1] http://images.armcloud.us/kernel-ci/mainline/v3.17-rc5-25-g8ba4caf/arm-multi_v7_defconfig/boot-exynos5420-arndale-octa.html [2] http://images.armcloud.us/kernel-ci/mainline/v3.17-rc5-25-g8ba4caf/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: fix plane-framebuffer linkage
Hi, On 09/18/2014 01:41 AM, Daniel Drake wrote: > On Wed, Sep 17, 2014 at 7:45 AM, Daniel Vetter wrote: >> I think fb refcounting in exynos is just plain busted. If you look at >> other drivers the only place the refcount framebuffers or backing >> storage objects is for pageflips to make sure the memory doesn't go >> away while the hw is still scanning out the old framebuffer. If you >> refcount anywhere else you either do something really crazy or your >> driver is broken. > > With my patch actually the behaviour is much more similar to omapdrm, Your patch will occur fb reference count problem when setplane. > which also doesn't quite match your description of "other drivers". > See omap_plane.c. > > There is a fb reference taken for "pinning" in update_pin() which > presumably is what you describe - avoid destroying the fb while it is > being scanned out. (Maybe exynos should have something equivalent too, > but thats a separate issue) > > However there is *another* fb reference taken in > omap_plane_mode_set(). And my patch is modelled to do the same in > exynos-drm. > > I believe this is necessary under the current model. At least, when > drm_mode_rmfb() is running for the last user of the active > framebuffer, it expects to drop 3 references from the framebuffer > before dropping the 4th causes the object to be destroyed, as follows: > > 1. drm_mode_rmfb explicitly drops a reference - it calls > __drm_framebuffer_unregister which then calls > __drm_framebuffer_unreference > /* Mark fb as reaped, we still have a ref from fpriv->fbs. */ > __drm_framebuffer_unregister(dev, fb); > > 2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls > drm_mode_set_config_internal() in order to turn off the CRTC, dropping > another reference in the process. > if (tmp->old_fb) > drm_framebuffer_unreference(tmp->old_fb); > > 3. drm_framebuffer_remove calls drm_plane_force_disable() which drops > another reference: > /* disconnect the plane from the fb and crtc: */ > __drm_framebuffer_unreference(old_fb); This call is new path, before universal planes merged, private plane of exynos crtc wasn't included in dev->mode_config.plane_list because private plane wasn't exposed to userspace so this path wasn't called. > > 4. drm_framebuffer drops the final reference itself, to cause freeing > of the object: > drm_framebuffer_unreference(fb); > > > So ordinarily, after a fb is created by drm core (with refcnt at 1), > there would have to be 3 references added to it by the time it is the > primary fb so that when we do rmfb, it has a refcnt of 4, and gets > freed correctly. > (The second bug I was seeing with pageflips was that refcnt was 3, > which means that the final reference was dropped in (3) above, but > __drm_framebuffer_unreference doesn't like that at all - it calls > drm_framebuffer_free_bug) > > Not being overly familiar with DRM internals I tried to go backwards > to find out where these 3 references would be created during normal > operation. 2 are clear: > > 1. drm_framebuffer_init() explicitly grabs one: > /* Grab the idr reference. */ > drm_framebuffer_reference(fb) > > 2. drm_mode_set_config_internal() takes one: > if (tmp->primary->fb) > drm_framebuffer_reference(tmp->primary->fb); > > Where should the 3rd one be created? I don't know, but looking at > previous exynos commit 25c8b5c304 and omapdrm, I assumed that the drm > driver should take one, both on crtc mode set and crtc page flip. So Andrzej added fb reference count increasing in crtc modeset path, but i think we can take away this workaround if remove private plane for exynos crtc. Thanks. > >>> However, I'll be happy if universal planes means the driver does not >>> have to care about this any more. Andrej, please go ahead if you are >>> interested, I'll be happy to test your results. >> >> universal planes will fix up the mess with 2 drm plane objects >> (primary plane + exonys internal primary). So should help to untangle >> this not, but it will not magically fix the refcounting bugs itself. > > So even when we move to universal planes (fixing 1 of the issues), its > good that we're having this refcount discussion (which we need to > understand to confidently solve the 2nd issue). Thanks for your input! > > Daniel > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] arm: exynos: Allow rtc alarm and tick wakeup irq for exynos3250.
On 2014년 09월 17일 17:53, Vikas Sajjan wrote:
> Hi,
>
> On Wed, Sep 17, 2014 at 8:52 AM, Jonghwa Lee wrote:
>> Add rtc alarm and tick irq to wakeup sources in exynos3250.
>>
>> Signed-off-by: Jonghwa Lee
>> Acked-by : Chanwoo choi
>> ---
>> arch/arm/mach-exynos/pm.c |9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
>> index fa7218a..d78dcf9 100644
>> --- a/arch/arm/mach-exynos/pm.c
>> +++ b/arch/arm/mach-exynos/pm.c
>> @@ -66,6 +66,12 @@ static struct sleep_save exynos_core_save[] = {
>>
>> static u32 exynos_irqwake_intmask = 0x;
>>
>> +static const struct exynos_wkup_irq exynos3250_wkup_irq[] = {
>> + { 105, BIT(1) }, /* RTC alarm */
>> + { 106, BIT(2) }, /* RTC tick */
>> + { /* sentinel */ },
>> +};
>> +
>> static const struct exynos_wkup_irq exynos4_wkup_irq[] = {
>> { 76, BIT(1) }, /* RTC alarm */
>> { 77, BIT(2) }, /* RTC tick */
>> @@ -81,9 +87,10 @@ static const struct exynos_wkup_irq exynos5250_wkup_irq[]
>> = {
>> static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
>> {
>> const struct exynos_wkup_irq *wkup_irq;
>> -
>> if (soc_is_exynos5250())
>> wkup_irq = exynos5250_wkup_irq;
>> + else if (soc_is_exynos3250())
>> + wkup_irq = exynos3250_wkup_irq;
>
>
> Don't add anymore soc_is_exynosxxx() checks, please rebase on [1],
> which refactors the pm.c to use DT based lookup.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg355266.html
>
Okay, I'll wait those patches are merged, then I'll rebase and repost it.
Thanks,
Jonghwa.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] phy: exynos-dp-video: Use syscon support to control pmu register
Hi Kishon,
On Wed, Sep 17, 2014 at 10:24 PM, Kishon Vijay Abraham I wrote:
>
>
> On Tuesday 16 September 2014 10:32 AM, Vivek Gautam wrote:
>> Currently the DP_PHY_ENABLE register is mapped in the driver,
>> and accessed to control power to the PHY.
>> With mfd-syscon and regmap interface available at our disposal,
>> it's wise to use that instead of using a 'reg' property for the
>> controller and allocating a memory resource for that.
>>
>> To facilitate this, we have added another compatible string
>> for Exynso5420 SoC to acquire driver data which contains
>> different DP-PHY-CONTROL register offset.
>>
>> Signed-off-by: Vivek Gautam
>> Cc: Jingoo Han
>> Cc: Kishon Vijay Abraham I
>
> Taking this in linux-phy tree. If someone has already taken this patch, please
> let me know.
Thanks for taking this. But just one check, i think i need to separate
out the Documentation
to a separate patch even before this driver patch. Isn't it ?
>
> Thanks
> Kishon
>
>> ---
>>
>> Changes since v2:
>> - Using 'EXYNOS5_PHY_ENABLE' macro instead of 'EXYNOS_DPTX_PHY_ENABLE'
>>since that's available with us in "linux/mfd/syscon/exynos5-pmu.h" file.
>>
>> Changes since v1:
>> - state->regs should have been "struct regmap *" instead of
>>"void __iomem *". So corrected the same.
>>
>> .../devicetree/bindings/phy/samsung-phy.txt|7 +-
>> drivers/phy/phy-exynos-dp-video.c | 79
>> +---
>> 2 files changed, 59 insertions(+), 27 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index 7a6feea..15e0f2c 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
>> -
>>
>> Required properties:
>> -- compatible : should be "samsung,exynos5250-dp-video-phy";
>> -- reg : offset and length of the Display Port PHY register set;
>> +- compatible : should be one of the following supported values:
>> + - "samsung,exynos5250-dp-video-phy"
>> + - "samsung,exynos5420-dp-video-phy"
>> +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
>> + control pmu registers for power isolation.
>> - #phy-cells : from the generic PHY bindings, must be 0;
>>
>> Samsung S5P/EXYNOS SoC series USB PHY
>> diff --git a/drivers/phy/phy-exynos-dp-video.c
>> b/drivers/phy/phy-exynos-dp-video.c
>> index 8b3026e..53f44a0 100644
>> --- a/drivers/phy/phy-exynos-dp-video.c
>> +++ b/drivers/phy/phy-exynos-dp-video.c
>> @@ -13,44 +13,55 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include
>> #include
>> #include
>> #include
>> +#include
>>
>> -/* DPTX_PHY_CONTROL register */
>> -#define EXYNOS_DPTX_PHY_ENABLE (1 << 0)
>> +struct exynos_dp_video_phy_drvdata {
>> + u32 phy_ctrl_offset;
>> +};
>>
>> struct exynos_dp_video_phy {
>> - void __iomem *regs;
>> + struct regmap *regs;
>> + const struct exynos_dp_video_phy_drvdata *drvdata;
>> };
>>
>> -static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int
>> on)
>> +static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
>> + unsigned int on)
>> {
>> - u32 reg;
>> + unsigned int val;
>> +
>> + if (IS_ERR(state->regs))
>> + return;
>>
>> - reg = readl(state->regs);
>> - if (on)
>> - reg |= EXYNOS_DPTX_PHY_ENABLE;
>> - else
>> - reg &= ~EXYNOS_DPTX_PHY_ENABLE;
>> - writel(reg, state->regs);
>> + val = on ? 0 : EXYNOS5_PHY_ENABLE;
>>
>> - return 0;
>> + regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
>> +EXYNOS5_PHY_ENABLE, val);
>> }
>>
>> static int exynos_dp_video_phy_power_on(struct phy *phy)
>> {
>> struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>
>> - return __set_phy_state(state, 1);
>> + /* Disable power isolation on DP-PHY */
>> + exynos_dp_video_phy_pwr_isol(state, 0);
>> +
>> + return 0;
>> }
>>
>> static int exynos_dp_video_phy_power_off(struct phy *phy)
>> {
>> struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>
>> - return __set_phy_state(state, 0);
>> + /* Enable power isolation on DP-PHY */
>> + exynos_dp_video_phy_pwr_isol(state, 1);
>> +
>> + return 0;
>> }
>>
>> static struct phy_ops exynos_dp_video_phy_ops = {
>> @@ -59,11 +70,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
>> .owner = THIS_MODULE,
>> };
>>
>> +static const struct exynos_dp_video_phy_drvdata exynos5250_dp_video_phy = {
>> + .phy_ctrl_offset= EXYNOS5_DPTX_PHY_CONTROL,
>> +};
>> +
>> +static const struct exynos_dp_video_phy_drvdata exynos5420_dp_video_phy = {
>> +
RE: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices
+CC: Dong Aisheng Hi Arnd, On Wednesday, September 17, 2014, Arnd Bergmann wrote, > > V2 of this patchset and related discussion can be found here [1]. > > > > Changes since v2: > > - Added back platform device support from syscon, with one change that > >syscon will not be probed for DT based platform. > > - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base > >users of syscon will not be broken. > > - Removed unwanted change in syscon.h. > > - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and > >Arnd Bergmann. > > - Added Tested-by of Vivek Gautam for testing on Exynos platform. > > Looks fine. Provided you can figure out the problem that Dong Aisheng reported, > please add my > > Acked-by: Arnd Bergmann > Thanks. After he reported I have again done code walk-through of regmap_init_mmio and could not see any such fatal error. At the same time I have replied to Dong Aisheng, asking for more details and waiting for his reply. > > -} > > +static struct syscon *of_syscon_register(struct device_node *np); > > > > One minor comment: please avoid doing forward declarations of local functions. It > took me a while to understand what is going on because I expect all functions to be > ordered such that they only get called by functions below, and don't need this. > > Just move of_syscon_register() here directly. > OK, I will remove forward declaration of "of_syscon_register" and respin patch once again. > Arnd Thanks, Pankaj Dubey -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices
On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
> Hi,
>
> On Wednesday, September 17, 2014, Dong Aisheng Wrote,
> > >
> > > +static struct syscon *of_syscon_register(struct device_node *np) {
> > > + struct syscon *syscon;
> > > + struct regmap *regmap;
> > > + void __iomem *base;
> > > +
> > > + if (!of_device_is_compatible(np, "syscon"))
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
> > > + if (!syscon)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + base = of_iomap(np, 0);
> > > + if (!base)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + regmap = regmap_init_mmio(NULL, base, &syscon_regmap_config);
> >
> > Does a NULL device pointer work?
>
> Yes, it is safe, at least we are able to test on Exynos based SoC.
> I have tested it with kgene/for-next kernel on Exynos3250.
> Also it has been tested on Exynos5250 based Snow board with 3.17-rc5 based
> kernel
> by Vivek Gautam.
>
> Patch V2 also has been tested by "Borris Brezillon" on AT91 platform.
>
>
The kernel i tested was next-20140915 of linux-next.
please see regmap_get_val_endian called in regmap_init function.
static enum regmap_endian regmap_get_val_endian(struct device *dev,
const struct regmap_bus *bus,
const struct regmap_config *config)
{
struct device_node *np = dev->of_node;
enum regmap_endian endian;
...
}
It will crash at the first line of dev->of_node if dev is NULL.
Can you check if you're using the same code as mine?
> > I just tested on MX6SX SDB board and it seemed crashed at here in
> regmap_init
> > function.
> >
>
> Can you please provide crash log which can give more information about the
> crash?
>
My crash log is:
[0.225148] Unable to handle kernel NULL pointer dereference at virtual
address 01d4
[0.233383] pgd = 80004000
[0.236185] [01d4] *pgd=
[0.239873] Internal error: Oops: 5 [#1] SMP ARM
[0.244588] Modules linked in:
[0.247753] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.17.0-rc4-next-20140915-6-g8ba2dd0-dirty #421
[0.257342] task: bd878000 ti: bd88 task.ti: bd88
[0.262848] PC is at regmap_init+0x21c/0xab4
[0.267221] LR is at vprintk_emit+0x254/0x5e0
[0.271677] pc : [<80389420>]lr : [<8006a4f8>]psr: 6153
[0.271677] sp : bd881ae0 ip : bd881a48 fp : bd881b1c
[0.283354] r10: r9 : bd8e1850 r8 : 0003
[0.288678] r7 : r6 : 8098fccc r5 : 8098ee0c r4 : bd8f4e00
[0.295307] r3 : bd878000 r2 : 01e5 r1 : 806ee8f0 r0 : 808762c0
[0.301938] Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment
kernel
[0.309438] Control: 10c5387d Table: 8000404a DAC: 0015
[0.315284] Process swapper/0 (pid: 1, stack limit = 0xbd880240)
[0.321391] Stack: (0xbd881ae0 to 0xbd882000)
[0.325851] 1ae0: bd8e1850 bd881b1c bd881af8 8038f580 8098fccc
be7d49b8
[0.334136] 1b00: 8098fca4 bd917000 bd8e1850 bd881b34 bd881b20
8038f68c 80389210
[0.342422] 1b20: bd91b480 8098fcc4 bd881b5c bd881b38 80398b24 8038f664
bd91ac10
[0.350708] 1b40: be7d4bc0 bd917010 bd917000 bd8e1850 bd881bac bd881b60
803185a4 80398a54
[0.358993] 1b60: bd881b94 bd881b70
[0.367277] 1b80: bd917010 80983a64 bd916c10
80983a64
[0.375563] 1ba0: bd881bc4 bd881bb0 8037bb44 80318510 811c65f0 bd917010
bd881bec bd881bc8
[0.383848] 1bc0: 8037a104 8037bb1c 80983a64 bd917010 8037a23c bd916c10
[0.392134] 1be0: bd881c04 bd881bf0 8037a284 8037a004 bd917010
bd881c2c bd881c08
[0.400419] 1c00: 80378614 8037a248 bd8038d8 bd8af7d4 bd916c10 bd917010
bd917044 8098e308
[0.408704] 1c20: bd881c4c bd881c30 80379fb8 803785c0 bd803800 bd917018
bd917010 8098e308
[0.416990] 1c40: bd881c6c bd881c50 8037961c 80379f48 bd917018
bd917010
[0.425275] 1c60: bd881ca4 bd881c70 80377904 80379598 bd881cc8 bd881cc0
bd881cb8 bd881c88
[0.433560] 1c80: be7d4bc0 bd916c10 0001 bd917000 be7d4c10
bd881cb4 bd881ca8
[0.441845] 1ca0: 804f1708 803774e8 bd881cfc bd881cb8 804f1f2c 804f16dc
bd881cdc bd881cc8
[0.450130] 1cc0: 806b6d7c 80060478 809b0220 6153 bd881cfc
be7d4bc0
[0.458415] 1ce0: 0001 8070bb80 bd916c10 bd881d5c bd881d00
804f2068 804f1e5c
[0.466700] 1d00: bd878000 a153 809b0220 bd881d2c bd881d20
80060480 80060284
[0.474985] 1d20: bd881d44 bd881d30 806b6d7c 80060478 be7d4bc0
be7d49b8
[0.483270] 1d40: 0001 8070bb80 bd916c10 bd881dbc bd881d60
804f20c4 804f1f8c
[0.491556] 1d60: 0001 6153 809b0220 bd881d8c bd881d80
80060480 80060284
[0.499841] 1d80: bd881da4 bd881d90 806b6d7c 80060478 be7d46f8 be7d49b8
be7cf764
Re: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices
On Thu, Sep 18, 2014 at 08:59:32AM +0530, Pankaj Dubey wrote: > +CC: Dong Aisheng > > Hi Arnd, > > On Wednesday, September 17, 2014, Arnd Bergmann wrote, > > > V2 of this patchset and related discussion can be found here [1]. > > > > > > Changes since v2: > > > - Added back platform device support from syscon, with one change that > > >syscon will not be probed for DT based platform. > > > - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base > > >users of syscon will not be broken. > > > - Removed unwanted change in syscon.h. > > > - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and > > >Arnd Bergmann. > > > - Added Tested-by of Vivek Gautam for testing on Exynos platform. > > > > Looks fine. Provided you can figure out the problem that Dong Aisheng > reported, > > please add my > > > > Acked-by: Arnd Bergmann > > > > Thanks. > After he reported I have again done code walk-through of regmap_init_mmio > and > could not see any such fatal error. At the same time I have replied to Dong > Aisheng, > asking for more details and waiting for his reply. > I just replied and gave the log. Regards Dong Aisheng > > > -} > > > +static struct syscon *of_syscon_register(struct device_node *np); > > > > > > > One minor comment: please avoid doing forward declarations of local > functions. It > > took me a while to understand what is going on because I expect all > functions to be > > ordered such that they only get called by functions below, and don't need > this. > > > > Just move of_syscon_register() here directly. > > > > OK, I will remove forward declaration of "of_syscon_register" and respin > patch once again. > > > Arnd > > Thanks, > Pankaj Dubey > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
Hi Alan,
On Wed, Sep 17, 2014 at 8:27 PM, Alan Stern wrote:
> On Wed, 17 Sep 2014, Vivek Gautam wrote:
>
>> Now that we have completely moved from older USB-PHY drivers
>> to newer GENERIC-PHY drivers for PHYs available with USB controllers
>> on Exynos series of SoCs, we can remove the support for the same
>> in our host drivers too.
>>
>> Signed-off-by: Vivek Gautam
>
> I don't see why you made your changes in this awkward way. For
> instance...
>
>> @@ -59,49 +54,39 @@ static int exynos_ehci_get_phy(struct device *dev,
>> {
>> struct device_node *child;
>> struct phy *phy;
>> - int phy_number;
>> - int ret = 0;
>> + int phy_num;
>
> Why rename this variable? Wasn't the original name good enough?
fair enough, don't need to rename the variable.
>
>> + int ret;
>>
>> for_each_available_child_of_node(dev->of_node, child) {
>> - ret = of_property_read_u32(child, "reg", &phy_number);
>> + ret = of_property_read_u32(child, "reg", &phy_num);
>> if (ret) {
>> dev_err(dev, "Failed to parse device tree\n");
>> of_node_put(child);
>> return ret;
>> }
>>
>> - if (phy_number >= PHY_NUMBER) {
>> + if (phy_num >= PHY_NUMBER) {
>> dev_err(dev, "Invalid number of PHYs\n");
>> of_node_put(child);
>> return -EINVAL;
>> }
>>
>> - phy = devm_of_phy_get(dev, child, NULL);
>> + exynos_ehci->phy[phy_num] = devm_of_phy_get(dev, child, NULL);
>> + phy = exynos_ehci->phy[phy_num];
>
> Why make two changes, resulting in more code, when you could have made
> just one change?
>
> phy = devm_of_phy_get(dev, child, NULL);
> + exynos_ehci->phy[phy_num] = phy;
Right. i don't know what state of mind i was in while making these changes.
i should have kept the changes to minimal.
>
> Also, the patch description should mention that you are adding support
> for EPROBE_DEFER.
Sure, will add that description.
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.
Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
Cc: Alan Stern
---
Changes since v3:
- Addressed review comments by Alan:
-- Skipped renaming 'phy_number' variable,
-- resorted to just adding minimal change required for phy assignment.
-- updated patch description to mention EPROBE_DEFER support.
drivers/usb/host/ehci-exynos.c | 74 +++-
1 file changed, 20 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 2eed9a4..f293453 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
#include "ehci.h"
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
struct exynos_ehci_hcd {
struct clk *clk;
- struct usb_phy *phy;
- struct usb_otg *otg;
- struct phy *phy_g[PHY_NUMBER];
+ struct phy *phy[PHY_NUMBER];
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
@@ -60,8 +55,9 @@ static int exynos_ehci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
- int ret = 0;
+ int ret;
+ /* Get PHYs for the controller */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", &phy_number);
if (ret) {
@@ -77,31 +73,21 @@ static int exynos_ehci_get_phy(struct device *dev,
}
phy = devm_of_phy_get(dev, child, NULL);
+ exynos_ehci->phy[phy_number] = phy;
of_node_put(child);
- if (IS_ERR(phy))
- /* Lets fallback to older USB-PHYs */
- goto usb_phy_old;
- exynos_ehci->phy_g[phy_number] = phy;
- /* Make the older PHYs unavailable */
- exynos_ehci->phy = ERR_PTR(-ENXIO);
- }
-
- return 0;
-
-usb_phy_old:
- exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(exynos_ehci->phy)) {
- ret = PTR_ERR(exynos_ehci->phy);
- if (ret != -ENXIO && ret != -ENODEV) {
- dev_err(dev, "no usb2 phy configured\n");
- return ret;
+ if (IS_ERR(phy)) {
+ ret = PTR_ERR(phy);
+ if (ret == -EPROBE_DEFER) {
+ return ret;
+ } else if (ret != -ENOSYS && ret != -ENODEV) {
+ dev_err(dev,
+ "Error retrieving usb2 phy: %d\n", ret);
+ return PTR_ERR(phy);
+ }
}
- dev_dbg(dev, "Failed to get usb2 phy\n");
- } else {
- exynos_ehci->otg = exynos_ehci->phy->otg;
}
- return ret;
+ return 0;
}
static int exynos_ehci_phy_enable(struct device *dev)
@@ -111,16 +97,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
- if (!IS_ERR(exynos_ehci->phy))
- return usb_phy_init(exynos_ehci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ehci->phy_g[i]))
- ret = phy_power_on(exynos_ehci->phy_g[i]);
+ if (!IS_ERR(exynos_ehci->phy[i]))
+ ret = phy_power_on(exynos_ehci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
- if (!IS_ERR(exynos_ehci->phy_g[i]))
- phy_power_off(exynos_ehci->phy_g[i]);
+ if (!IS_ERR(exynos_ehci->phy[i]))
+ phy_power_off(exynos_ehci->phy[i]);
return ret;
}
@@ -131,14 +114,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
- if (!IS_ERR(exynos_ehci->phy)) {
- usb_phy_shutdown(exynos_ehci->phy);
- return;
- }
-
for (i = 0; i < PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ehci->phy_g[i]))
- phy_power_off(exynos_ehci->phy_g[i]);
+ if (!IS_ERR(exynos_ehci->phy[i]))
+ phy_power_off(exynos_ehci->phy[i]);
}
static void exynos_setup_vbus_gpio(struct device *dev)
@@ -231,9 +209,6 @@ skip_phy:
goto fail_io;
}
- if (exynos_ehci->otg)
-
[PATCH v4 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.
Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
Cc: Alan Stern
---
Changes since v3:
- Addressed review comments by Alan:
-- Skipped renaming 'phy_number' variable,
-- resorted to just adding minimal change required for phy assignment.
-- updated patch description to mention EPROBE_DEFER support.
drivers/usb/host/ohci-exynos.c | 81 ++--
1 file changed, 20 insertions(+), 61 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 7c48e3f..e8bf4bb 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -19,11 +19,8 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
#include "ohci.h"
@@ -38,9 +35,7 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
struct exynos_ohci_hcd {
struct clk *clk;
- struct usb_phy *phy;
- struct usb_otg *otg;
- struct phy *phy_g[PHY_NUMBER];
+ struct phy *phy[PHY_NUMBER];
};
static int exynos_ohci_get_phy(struct device *dev,
@@ -49,15 +44,9 @@ static int exynos_ohci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
- int ret = 0;
+ int ret;
- /*
-* Getting generic phy:
-* We are keeping both types of phys as a part of transiting OHCI
-* to generic phy framework, so as to maintain backward compatibilty
-* with old DTB too.
-* We fallback to older USB-PHYs when we fail to get generic PHYs.
-*/
+ /* Get PHYs for the controller */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", &phy_number);
if (ret) {
@@ -73,31 +62,21 @@ static int exynos_ohci_get_phy(struct device *dev,
}
phy = devm_of_phy_get(dev, child, NULL);
+ exynos_ohci->phy[phy_number] = phy;
of_node_put(child);
- if (IS_ERR(phy))
- /* Lets fallback to older USB-PHYs */
- goto usb_phy_old;
- exynos_ohci->phy_g[phy_number] = phy;
- /* Make the older PHYs unavailable */
- exynos_ohci->phy = ERR_PTR(-ENXIO);
- }
-
- return 0;
-
-usb_phy_old:
- exynos_ohci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(exynos_ohci->phy)) {
- ret = PTR_ERR(exynos_ohci->phy);
- if (ret != -ENXIO && ret != -ENODEV) {
- dev_err(dev, "no usb2 phy configured\n");
- return ret;
+ if (IS_ERR(phy)) {
+ ret = PTR_ERR(phy);
+ if (ret == -EPROBE_DEFER) {
+ return ret;
+ } else if (ret != -ENOSYS && ret != -ENODEV) {
+ dev_err(dev,
+ "Error retrieving usb2 phy: %d\n", ret);
+ return PTR_ERR(phy);
+ }
}
- dev_dbg(dev, "Failed to get usb2 phy\n");
- } else {
- exynos_ohci->otg = exynos_ohci->phy->otg;
}
- return ret;
+ return 0;
}
static int exynos_ohci_phy_enable(struct device *dev)
@@ -107,16 +86,13 @@ static int exynos_ohci_phy_enable(struct device *dev)
int i;
int ret = 0;
- if (!IS_ERR(exynos_ohci->phy))
- return usb_phy_init(exynos_ohci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ohci->phy_g[i]))
- ret = phy_power_on(exynos_ohci->phy_g[i]);
+ if (!IS_ERR(exynos_ohci->phy[i]))
+ ret = phy_power_on(exynos_ohci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
- if (!IS_ERR(exynos_ohci->phy_g[i]))
- phy_power_off(exynos_ohci->phy_g[i]);
+ if (!IS_ERR(exynos_ohci->phy[i]))
+ phy_power_off(exynos_ohci->phy[i]);
return ret;
}
@@ -127,14 +103,9 @@ static void exynos_ohci_phy_disable(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
int i;
- if (!IS_ERR(exynos_ohci->phy)) {
- usb_phy_shutdown(exynos_ohci->phy);
- return;
- }
-
for (i = 0; i < PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ohci->phy_g[i]))
- phy_power_off(exynos_ohci->phy_g[i]);
+
Re: [PATCH 2/2] drm/exynos: use drm generic mmap interface
Hi,
On 09/17/2014 10:48 PM, Inki Dae wrote:
> This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
> to Exynos drm and instead uses drm generic mmap.
>
> We had used the interface specific to Exynos drm to do mmap directly,
> not to use demand paging which maps each page with physical memory
> at page fault handler. We don't need the specific mmap interface
> because the drm generic mmap which uses vm offset manager stuff can
> also do mmap directly.
>
> This patch makes a userspace region to be mapped with whole physical
> memory region allocated by userspace request when mmap system call is
> requested.
>
> Signed-off-by: Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 25 -
> drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 84
> ++-
> drivers/gpu/drm/exynos/exynos_drm_gem.h | 10
> include/uapi/drm/exynos_drm.h | 22
> 5 files changed, 14 insertions(+), 128 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 10ad3d4..a7819eb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
Because anymore anon file doesn't use, you can remove to include
.
> @@ -149,10 +149,6 @@ static int exynos_drm_unload(struct drm_device *dev)
> return 0;
> }
>
> -static const struct file_operations exynos_drm_gem_fops = {
> - .mmap = exynos_drm_gem_mmap_buffer,
> -};
> -
> static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
> {
> struct drm_connector *connector;
> @@ -191,7 +187,6 @@ static int exynos_drm_resume(struct drm_device *dev)
> static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
> {
> struct drm_exynos_file_private *file_priv;
> - struct file *anon_filp;
> int ret;
>
> file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
> @@ -204,21 +199,8 @@ static int exynos_drm_open(struct drm_device *dev,
> struct drm_file *file)
> if (ret)
> goto err_file_priv_free;
>
> - anon_filp = anon_inode_getfile("exynos_gem", &exynos_drm_gem_fops,
> - NULL, 0);
> - if (IS_ERR(anon_filp)) {
> - ret = PTR_ERR(anon_filp);
> - goto err_subdrv_close;
> - }
> -
> - anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
> - file_priv->anon_filp = anon_filp;
> -
> return ret;
>
> -err_subdrv_close:
> - exynos_drm_subdrv_close(dev, file);
> -
> err_file_priv_free:
> kfree(file_priv);
> file->driver_priv = NULL;
> @@ -234,7 +216,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
> static void exynos_drm_postclose(struct drm_device *dev, struct drm_file
> *file)
> {
> struct exynos_drm_private *private = dev->dev_private;
> - struct drm_exynos_file_private *file_priv;
> struct drm_pending_vblank_event *v, *vt;
> struct drm_pending_event *e, *et;
> unsigned long flags;
> @@ -260,10 +241,6 @@ static void exynos_drm_postclose(struct drm_device *dev,
> struct drm_file *file)
> }
> spin_unlock_irqrestore(&dev->event_lock, flags);
>
> - file_priv = file->driver_priv;
> - if (file_priv->anon_filp)
> - fput(file_priv->anon_filp);
> -
> kfree(file->driver_priv);
> file->driver_priv = NULL;
> }
> @@ -282,8 +259,6 @@ static const struct vm_operations_struct
> exynos_drm_gem_vm_ops = {
> static const struct drm_ioctl_desc exynos_ioctls[] = {
> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
> DRM_UNLOCKED | DRM_AUTH),
> - DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
> - exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
> exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 69a6fa3..d22e640 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -240,7 +240,6 @@ struct exynos_drm_g2d_private {
> struct drm_exynos_file_private {
> struct exynos_drm_g2d_private *g2d_priv;
> struct device *ipp_dev;
> - struct file *anon_filp;
> };
>
> /*
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 2f3665d..3cf6494 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -318,21 +318,17 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
> drm_gem_object_unreference_unlocked(obj);
> }
>
> -int exynos_drm_gem_mmap_buffer(struct file *filp,
> +int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj *exynos_gem_obj,
>
Re: [PATCH 2/2] drm/exynos: use drm generic mmap interface
Thanks for review.
Below trivial things you pointed out will be fixed soon.
On 2014년 09월 18일 13:56, Joonyoung Shim wrote:
> Hi,
>
> On 09/17/2014 10:48 PM, Inki Dae wrote:
>> This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
>> to Exynos drm and instead uses drm generic mmap.
>>
>> We had used the interface specific to Exynos drm to do mmap directly,
>> not to use demand paging which maps each page with physical memory
>> at page fault handler. We don't need the specific mmap interface
>> because the drm generic mmap which uses vm offset manager stuff can
>> also do mmap directly.
>>
>> This patch makes a userspace region to be mapped with whole physical
>> memory region allocated by userspace request when mmap system call is
>> requested.
>>
>> Signed-off-by: Inki Dae
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 25 -
>> drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 84
>> ++-
>> drivers/gpu/drm/exynos/exynos_drm_gem.h | 10
>> include/uapi/drm/exynos_drm.h | 22
>> 5 files changed, 14 insertions(+), 128 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index 10ad3d4..a7819eb 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>
> Because anymore anon file doesn't use, you can remove to include
> .
Right, I missed it while taking away the direct mmap stuff specific to
Exynos drm.
>
>> @@ -149,10 +149,6 @@ static int exynos_drm_unload(struct drm_device *dev)
>> return 0;
>> }
>>
>> -static const struct file_operations exynos_drm_gem_fops = {
>> -.mmap = exynos_drm_gem_mmap_buffer,
>> -};
>> -
>> static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
>> {
>> struct drm_connector *connector;
>> @@ -191,7 +187,6 @@ static int exynos_drm_resume(struct drm_device *dev)
>> static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
>> {
>> struct drm_exynos_file_private *file_priv;
>> -struct file *anon_filp;
>> int ret;
>>
>> file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
>> @@ -204,21 +199,8 @@ static int exynos_drm_open(struct drm_device *dev,
>> struct drm_file *file)
>> if (ret)
>> goto err_file_priv_free;
>>
>> -anon_filp = anon_inode_getfile("exynos_gem", &exynos_drm_gem_fops,
>> -NULL, 0);
>> -if (IS_ERR(anon_filp)) {
>> -ret = PTR_ERR(anon_filp);
>> -goto err_subdrv_close;
>> -}
>> -
>> -anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
>> -file_priv->anon_filp = anon_filp;
>> -
>> return ret;
>>
>> -err_subdrv_close:
>> -exynos_drm_subdrv_close(dev, file);
>> -
>> err_file_priv_free:
>> kfree(file_priv);
>> file->driver_priv = NULL;
>> @@ -234,7 +216,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
>> static void exynos_drm_postclose(struct drm_device *dev, struct drm_file
>> *file)
>> {
>> struct exynos_drm_private *private = dev->dev_private;
>> -struct drm_exynos_file_private *file_priv;
>> struct drm_pending_vblank_event *v, *vt;
>> struct drm_pending_event *e, *et;
>> unsigned long flags;
>> @@ -260,10 +241,6 @@ static void exynos_drm_postclose(struct drm_device
>> *dev, struct drm_file *file)
>> }
>> spin_unlock_irqrestore(&dev->event_lock, flags);
>>
>> -file_priv = file->driver_priv;
>> -if (file_priv->anon_filp)
>> -fput(file_priv->anon_filp);
>> -
>> kfree(file->driver_priv);
>> file->driver_priv = NULL;
>> }
>> @@ -282,8 +259,6 @@ static const struct vm_operations_struct
>> exynos_drm_gem_vm_ops = {
>> static const struct drm_ioctl_desc exynos_ioctls[] = {
>> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
>> DRM_UNLOCKED | DRM_AUTH),
>> -DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
>> -exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
>> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
>> exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
>> DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 69a6fa3..d22e640 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -240,7 +240,6 @@ struct exynos_drm_g2d_private {
>> struct drm_exynos_file_private {
>> struct exynos_drm_g2d_private *g2d_priv;
>> struct device *ipp_dev;
>> -struct file *anon_filp;
>> };
>>
>> /*
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index 2f3665d..3cf6494 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exyn
[PATCH v2] drm/exynos: use drm generic mmap interface
This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
to Exynos drm and instead uses drm generic mmap.
We had used the interface specific to Exynos drm to do mmap directly,
not to use demand paging which maps each page with physical memory
at page fault handler. We don't need the specific mmap interface
because the drm generic mmap which uses vm offset manager stuff can
also do mmap directly.
This patch makes a userspace region to be mapped with whole physical
memory region allocated by userspace request when mmap system call is
requested.
Changelog v2:
- do not set VM_IO, VM_DONTEXPEND and VM_DONTDUMP. These flags were already
set by drm_gem_mmap
- do not include , which isn't needed anymore.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 26 -
drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
drivers/gpu/drm/exynos/exynos_drm_gem.c | 89 ++-
drivers/gpu/drm/exynos/exynos_drm_gem.h | 10
include/uapi/drm/exynos_drm.h | 22
5 files changed, 16 insertions(+), 132 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 10ad3d4..928c514 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -15,7 +15,6 @@
#include
#include
-#include
#include
#include
@@ -149,10 +148,6 @@ static int exynos_drm_unload(struct drm_device *dev)
return 0;
}
-static const struct file_operations exynos_drm_gem_fops = {
- .mmap = exynos_drm_gem_mmap_buffer,
-};
-
static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
{
struct drm_connector *connector;
@@ -191,7 +186,6 @@ static int exynos_drm_resume(struct drm_device *dev)
static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
{
struct drm_exynos_file_private *file_priv;
- struct file *anon_filp;
int ret;
file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
@@ -204,21 +198,8 @@ static int exynos_drm_open(struct drm_device *dev, struct
drm_file *file)
if (ret)
goto err_file_priv_free;
- anon_filp = anon_inode_getfile("exynos_gem", &exynos_drm_gem_fops,
- NULL, 0);
- if (IS_ERR(anon_filp)) {
- ret = PTR_ERR(anon_filp);
- goto err_subdrv_close;
- }
-
- anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
- file_priv->anon_filp = anon_filp;
-
return ret;
-err_subdrv_close:
- exynos_drm_subdrv_close(dev, file);
-
err_file_priv_free:
kfree(file_priv);
file->driver_priv = NULL;
@@ -234,7 +215,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
{
struct exynos_drm_private *private = dev->dev_private;
- struct drm_exynos_file_private *file_priv;
struct drm_pending_vblank_event *v, *vt;
struct drm_pending_event *e, *et;
unsigned long flags;
@@ -260,10 +240,6 @@ static void exynos_drm_postclose(struct drm_device *dev,
struct drm_file *file)
}
spin_unlock_irqrestore(&dev->event_lock, flags);
- file_priv = file->driver_priv;
- if (file_priv->anon_filp)
- fput(file_priv->anon_filp);
-
kfree(file->driver_priv);
file->driver_priv = NULL;
}
@@ -282,8 +258,6 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
- exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 69a6fa3..d22e640 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -240,7 +240,6 @@ struct exynos_drm_g2d_private {
struct drm_exynos_file_private {
struct exynos_drm_g2d_private *g2d_priv;
struct device *ipp_dev;
- struct file *anon_filp;
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 2f3665d..0d5b969 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -318,23 +318,16 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
}
-int exynos_drm_gem_mmap_buffer(struct file *filp,
+int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj *exynos_gem_obj,
struct vm
Re: [PATCH 7/9] phy: remove .owner field for drivers using module_platform_driver
On Thursday 18 September 2014 12:34 AM, Peter Griffin wrote: > Hi Kishon, > > On Wed, 17 Sep 2014, Kishon Vijay Abraham I wrote: > >> Hi, >> >> On Friday 15 August 2014 06:10 PM, Peter Griffin wrote: >>> This patch removes the superflous .owner field for drivers which >>> use the module_platform_driver or platform_driver_register api, >>> as this is overriden in __platform_driver_register. >>> >>> Signed-off-by: Peter Griffin > > >>> drivers/phy/phy-twl4030-usb.c | 1 - >> >> twl4030-usb doesn't use module_platform_driver. Care to resend this patch >> along? I've merged all other patches in this series. > > That is true, but it does use platform_driver_register whih overrides .owner. > So the patch is stil good I think (fyi see include/linux/platform_device.h). Indeed. Will merge this one. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
Hi Tomi,
On Wed, Sep 17, 2014 at 9:52 PM, Tomi Valkeinen wrote:
> On 17/09/14 17:29, Ajay kumar wrote:
>> Hi Tomi,
>>
>> Thanks for your comments.
>>
>> On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen
>> wrote:
>>> On 27/08/14 17:39, Ajay Kumar wrote:
Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/video/bridge/ps8622.txt| 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/bridge/ps8622.txt
diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..0ec8172
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,20 @@
+ps8622-bridge bindings
+
+Required properties:
+ - compatible: "parade,ps8622" or "parade,ps8625"
+ - reg: first i2c address of the bridge
+ - sleep-gpios: OF device-tree gpio specification for PD_ pin.
+ - reset-gpios: OF device-tree gpio specification for RST_ pin.
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+ - use-external-pwm: backlight will be controlled by an external PWM
>>>
>>> What does this mean? That the backlight support from ps8625 is not used?
>>> If so, maybe "disable-pwm" or something?
>> "use-external-pwm" or "disable-bridge-pwm" would be better.
>
> Well, the properties are about the bridge. "use-external-pwm" means that
> the bridge uses an external PWM, which, if I understood correctly, is
> not what the property is about.
>
> "disable-bridge-pwm" is ok, but the "bridge" there is extra. The
> properties are about the bridge, so it's implicit.
Ok. I will use "disable-pwm".
+
+Example:
+ lvds-bridge@48 {
+ compatible = "parade,ps8622";
+ reg = <0x48>;
+ sleep-gpios = <&gpc3 6 1 0 0>;
+ reset-gpios = <&gpc3 1 1 0 0>;
+ lane-count = <1>;
+ };
>>>
>>> I wish all new display component bindings would use the video
>>> ports/endpoints to describe the connections. It will be very difficult
>>> to improve the display driver model later if we're missing such critical
>>> pieces from the DT bindings.
>> Why do we need a complex graph when it can be handled using a simple phandle?
>
> Maybe in your case you can handle it with simple phandle. Can you
> guarantee that it's enough for everyone, on all platforms?
Yes, as of now exynos5420-peach-pit and exynos5250-spring boards use
this. In case of both, the phandle to bridge node is passed to the
exynos_dp node.
> The point of the ports/endpoint graph is to also support more
> complicated scenarios. If you now create ps8622 bindings that do not
> support those graphs, the no one else using ps8622 can use
> ports/endpoint graphs either.
>
> Btw, is there an example how the bridge with these bindings is used in a
> board's .dts file? I couldn't find any example with a quick search. So
> it's unclear to me what the "simple phandle" actually is.
Please refer to the following link:
https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/tree/arch/arm/boot/dts/exynos5420-peach-pit.dts?id=samsung-dt#n129
Let me know if you still think we would need to describe it as a complex graph!
Ajay
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] phy: exynos-dp-video: Use syscon support to control pmu register
On Thursday 18 September 2014 08:55 AM, Vivek Gautam wrote:
> Hi Kishon,
>
>
> On Wed, Sep 17, 2014 at 10:24 PM, Kishon Vijay Abraham I
> wrote:
>>
>>
>> On Tuesday 16 September 2014 10:32 AM, Vivek Gautam wrote:
>>> Currently the DP_PHY_ENABLE register is mapped in the driver,
>>> and accessed to control power to the PHY.
>>> With mfd-syscon and regmap interface available at our disposal,
>>> it's wise to use that instead of using a 'reg' property for the
>>> controller and allocating a memory resource for that.
>>>
>>> To facilitate this, we have added another compatible string
>>> for Exynso5420 SoC to acquire driver data which contains
>>> different DP-PHY-CONTROL register offset.
>>>
>>> Signed-off-by: Vivek Gautam
>>> Cc: Jingoo Han
>>> Cc: Kishon Vijay Abraham I
>>
>> Taking this in linux-phy tree. If someone has already taken this patch,
>> please
>> let me know.
>
> Thanks for taking this. But just one check, i think i need to separate
> out the Documentation
> to a separate patch even before this driver patch. Isn't it ?
no.. that's alright.
Thanks
Kishon
>
>>
>> Thanks
>> Kishon
>>
>>> ---
>>>
>>> Changes since v2:
>>> - Using 'EXYNOS5_PHY_ENABLE' macro instead of 'EXYNOS_DPTX_PHY_ENABLE'
>>>since that's available with us in "linux/mfd/syscon/exynos5-pmu.h" file.
>>>
>>> Changes since v1:
>>> - state->regs should have been "struct regmap *" instead of
>>>"void __iomem *". So corrected the same.
>>>
>>> .../devicetree/bindings/phy/samsung-phy.txt|7 +-
>>> drivers/phy/phy-exynos-dp-video.c | 79
>>> +---
>>> 2 files changed, 59 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> index 7a6feea..15e0f2c 100644
>>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> @@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
>>> -
>>>
>>> Required properties:
>>> -- compatible : should be "samsung,exynos5250-dp-video-phy";
>>> -- reg : offset and length of the Display Port PHY register set;
>>> +- compatible : should be one of the following supported values:
>>> + - "samsung,exynos5250-dp-video-phy"
>>> + - "samsung,exynos5420-dp-video-phy"
>>> +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
>>> + control pmu registers for power isolation.
>>> - #phy-cells : from the generic PHY bindings, must be 0;
>>>
>>> Samsung S5P/EXYNOS SoC series USB PHY
>>> diff --git a/drivers/phy/phy-exynos-dp-video.c
>>> b/drivers/phy/phy-exynos-dp-video.c
>>> index 8b3026e..53f44a0 100644
>>> --- a/drivers/phy/phy-exynos-dp-video.c
>>> +++ b/drivers/phy/phy-exynos-dp-video.c
>>> @@ -13,44 +13,55 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> -/* DPTX_PHY_CONTROL register */
>>> -#define EXYNOS_DPTX_PHY_ENABLE (1 << 0)
>>> +struct exynos_dp_video_phy_drvdata {
>>> + u32 phy_ctrl_offset;
>>> +};
>>>
>>> struct exynos_dp_video_phy {
>>> - void __iomem *regs;
>>> + struct regmap *regs;
>>> + const struct exynos_dp_video_phy_drvdata *drvdata;
>>> };
>>>
>>> -static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int
>>> on)
>>> +static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
>>> + unsigned int on)
>>> {
>>> - u32 reg;
>>> + unsigned int val;
>>> +
>>> + if (IS_ERR(state->regs))
>>> + return;
>>>
>>> - reg = readl(state->regs);
>>> - if (on)
>>> - reg |= EXYNOS_DPTX_PHY_ENABLE;
>>> - else
>>> - reg &= ~EXYNOS_DPTX_PHY_ENABLE;
>>> - writel(reg, state->regs);
>>> + val = on ? 0 : EXYNOS5_PHY_ENABLE;
>>>
>>> - return 0;
>>> + regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
>>> +EXYNOS5_PHY_ENABLE, val);
>>> }
>>>
>>> static int exynos_dp_video_phy_power_on(struct phy *phy)
>>> {
>>> struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>>
>>> - return __set_phy_state(state, 1);
>>> + /* Disable power isolation on DP-PHY */
>>> + exynos_dp_video_phy_pwr_isol(state, 0);
>>> +
>>> + return 0;
>>> }
>>>
>>> static int exynos_dp_video_phy_power_off(struct phy *phy)
>>> {
>>> struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>>
>>> - return __set_phy_state(state, 0);
>>> + /* Enable power isolation on DP-PHY */
>>> + exynos_dp_video_phy_pwr_isol(state, 1);
>>> +
>>> + return 0;
>>> }
>>>
>>> static struct phy_ops exynos_dp_video_phy_ops = {
>>> @@ -59,11 +70,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
>>> .owner = THI
RE: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices
Hi,
Adding CC to Xiubo Li, Geert Uytterhoeven and Stephen Warren.
On Thursday, September 18, 2014, Dong Aisheng wrote,
> On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
> > Hi,
> >
> > On Wednesday, September 17, 2014, Dong Aisheng Wrote,
> > > >
> > > > + regmap = regmap_init_mmio(NULL, base,
&syscon_regmap_config);
> > >
> > > Does a NULL device pointer work?
> >
> > Yes, it is safe, at least we are able to test on Exynos based SoC.
> > I have tested it with kgene/for-next kernel on Exynos3250.
> > Also it has been tested on Exynos5250 based Snow board with 3.17-rc5
> > based kernel by Vivek Gautam.
> >
> > Patch V2 also has been tested by "Borris Brezillon" on AT91 platform.
> >
> >
>
> The kernel i tested was next-20140915 of linux-next.
>
> please see regmap_get_val_endian called in regmap_init function.
> static enum regmap_endian regmap_get_val_endian(struct device *dev,
> const struct regmap_bus *bus,
> const struct regmap_config
*config) {
> struct device_node *np = dev->of_node;
> enum regmap_endian endian;
> ...
> }
> It will crash at the first line of dev->of_node if dev is NULL.
>
> Can you check if you're using the same code as mine?
No, it's not same.
My bad that I was not using linux-next for testing this patch.
We tested on kgene/for-next where these changes still have not come.
Just now I checked linux-next and found that it will crash at first line of
"regmap_get_val_endian" as there is no check for NULL on dev.
I checked git history of regmap.c file and found recently this file has been
modified
for adding DT endianness binding support. Following are set of patches gone
for this
cf673fb regmap: Split regmap_get_endian() in two functions
5844a8b regmap: Fix handling of volatile registers for format_write() chips
45e1a27 regmap: of_regmap_get_endian() cleanup
ba1b53f regmap: Fix DT endianess parsing logic
d647c19 regmap: add DT endianness binding support.
I think there should have been a check for NULL on "dev" in
"regmap_get_val_endian", so that if dev pointer exist then only it makes
sense to get
endianness property from DT.
I will suggest following fix in regmap.c for this. With following fix I
tested it and it works well
on linux-next also. So if you can confirm following fix is working for you
then I can post this
patch.
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev
and dev->of_node exist.
Signed-off-by: Pankaj Dubey
---
drivers/base/regmap/regmap.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index f2281af..455a877 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -477,7 +477,7 @@ static enum regmap_endian regmap_get_val_endian(struct
device *dev,
const struct regmap_bus *bus,
const struct regmap_config *config)
{
- struct device_node *np = dev->of_node;
+ struct device_node *np;
enum regmap_endian endian;
/* Retrieve the endianness specification from the regmap config */
@@ -487,15 +487,20 @@ static enum regmap_endian regmap_get_val_endian(struct
device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness specification */
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get endianness from DT
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that */
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an endianness
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey
> Regards
> Dong Aisheng
>
> >
> > Thanks,
> > Pankaj Dubey
> >
> > > Regards
> > > Dong Aisheng
> > >
> > > >
> > > >
Re: [PATCH] drm/exynos: fix plane-framebuffer linkage
On Wed, Sep 17, 2014 at 6:41 PM, Daniel Drake wrote: > However there is *another* fb reference taken in > omap_plane_mode_set(). And my patch is modelled to do the same in > exynos-drm. This is because omapdrm does _everything_ asynchrously, even plain modesets. Unfortunately that async modeset support is broken, so the latest omapdrm patches insert a synchronization point. So picking omap's mode_set logic as a reference because it also does fb refcounting is not a good idea - that code does something crazy and gets it wrong. And really, if you do modeset synchronously the drm core will take care of your refcounting needs. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: fix plane-framebuffer linkage
On Wed, Sep 17, 2014 at 6:41 PM, Daniel Drake wrote: > 2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls > drm_mode_set_config_internal() in order to turn off the CRTC, dropping > another reference in the process. > if (tmp->old_fb) > drm_framebuffer_unreference(tmp->old_fb); > > 3. drm_framebuffer_remove calls drm_plane_force_disable() which drops > another reference: > /* disconnect the plane from the fb and crtc: */ > __drm_framebuffer_unreference(old_fb); If 3. here is about the primary plane then this won't happen, since the primary plane pointer&reference has already been cleared in step 2. And even if their would be a bug in here, you _certainly_ should not try to paper over this in your driver, but instead fix up the refcounting done in the drm core. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow
Hello Doug, Andreas,
On 09/17/2014 05:47 PM, Doug Anderson wrote:
>>
>> rtc@101E {
>> status = "okay";
>> + clocks = <&clock CLK_RTC>, <&max77686 MAX77686_CLK_AP>;
>> + clock-names = "rtc", "rtc_src";
>
> Wait, seriously? Snow is still using the "rtc@101E" syntax?
> Whatever happened to the series that Andreas worked so hard on,
> including
