[PATCH v4 1/2] [media] v4l: Add source change event
This event indicates that the video device has encountered
a source parameter change during runtime. This can typically be a
resolution change detected by a video decoder OR a format change
detected by an HDMI connector.
This needs to be nofified to the userspace and the application may
be expected to reallocate buffers before proceeding. The application
can subscribe to events on a specific pad or input port which
it is interested in.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 32 +
.../DocBook/media/v4l/vidioc-subscribe-event.xml | 19 +++
drivers/media/v4l2-core/v4l2-event.c | 36
include/media/v4l2-event.h |4 +++
include/uapi/linux/videodev2.h |8 +
5 files changed, 99 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index 89891ad..6afabaa 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -242,6 +242,22 @@
/tgroup
/table
+table frame=none pgwide=1 id=v4l2-event-src-change
+ titlestruct structnamev4l2_event_src_change/structname/title
+ tgroup cols=3
+ cs-str;
+ tbody valign=top
+ row
+ entry__u32/entry
+ entrystructfieldchanges/structfield/entry
+ entry
+ A bitmask that tells what has changed. See xref
linkend=src-changes-flags /.
+ /entry
+ /row
+ /tbody
+ /tgroup
+/table
+
table pgwide=1 frame=none id=changes-flags
titleChanges/title
tgroup cols=3
@@ -270,6 +286,22 @@
/tbody
/tgroup
/table
+
+table pgwide=1 frame=none id=src-changes-flags
+ titleSource Changes/title
+ tgroup cols=3
+ cs-def;
+ tbody valign=top
+ row
+ entryconstantV4L2_EVENT_SRC_CH_RESOLUTION/constant/entry
+ entry0x0001/entry
+ entryThis event gets triggered when a resolution change is
+ detected at runtime. This can typically come from a video decoder.
+ /entry
+ /row
+ /tbody
+ /tgroup
+/table
/refsect1
refsect1
return-value;
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 5c70b61..067a0d5 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,25 @@
/entry
/row
row
+ entryconstantV4L2_EVENT_SOURCE_CHANGE/constant/entry
+ entry5/entry
+ entry
+ paraThis event is triggered when a source parameter change is
+ detected during runtime by the video device. It can be a
+ runtime resolution change triggered by a video decoder or the
+ format change happening on an HDMI connector.
+ This event requires that the structfieldid/structfield
+ matches the pad / input index from which you want to receive
+ events./para
+
+ paraThis event has a v4l2-event-source-change; associated
+ with it. The structfieldchanges/structfield bitfield denotes
+ what has changed for the subscribed pad. If multiple events
+ occured before application could dequeue them, then the changes
+ will have the ORed value of all the events generated./para
+ /entry
+ /row
+ row
entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
entry0x0800/entry
entryBase event number for driver-private events./entry
diff --git a/drivers/media/v4l2-core/v4l2-event.c
b/drivers/media/v4l2-core/v4l2-event.c
index 86dcb54..8761aab 100644
--- a/drivers/media/v4l2-core/v4l2-event.c
+++ b/drivers/media/v4l2-core/v4l2-event.c
@@ -318,3 +318,39 @@ int v4l2_event_subdev_unsubscribe(struct v4l2_subdev *sd,
struct v4l2_fh *fh,
return v4l2_event_unsubscribe(fh, sub);
}
EXPORT_SYMBOL_GPL(v4l2_event_subdev_unsubscribe);
+
+static void v4l2_event_src_replace(struct v4l2_event *old,
+ const struct v4l2_event *new)
+{
+ u32 old_changes = old-u.src_change.changes;
+
+ old-u.src_change = new-u.src_change;
+ old-u.src_change.changes |= old_changes;
+}
+
+static void v4l2_event_src_merge(const struct v4l2_event *old,
+ struct v4l2_event *new)
+{
+ new-u.src_change.changes |= old-u.src_change.changes;
+}
+
+static const struct v4l2_subscribed_event_ops v4l2_event_src_ch_ops = {
+ .replace = v4l2_event_src_replace,
+ .merge = v4l2_event_src_merge,
+};
+
+int v4l2_src_change_event_subscribe(struct v4l2_fh *fh,
+
Re: [PATCH v8 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Kishon, On Mon, May 12, 2014 at 6:33 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi Gautam, On Friday 09 May 2014 07:27 PM, Vivek Gautam wrote: Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. The new driver uses the generic PHY framework and will interact with DWC3 controller present on Exynos5 series of SoCs. Also, created a new header file in linux/mfd/syscon/ for Exynos5 SoCs and put the required PMU offset definitions for the basic available PHYs. I get the following checkpatch warnings WARNING: please write a paragraph that describes the config symbol fully #163: FILE: drivers/phy/Kconfig:163: +config PHY_EXYNOS5_USBDRD WARNING: DT compatible string samsung,exynos5250-usbdrd-phy appears un-documented -- check ./Documentation/devicetree/bindings/ #708: FILE: drivers/phy/phy-exynos5-usbdrd.c:516: + .compatible = samsung,exynos5250-usbdrd-phy, WARNING: DT compatible string samsung,exynos5420-usbdrd-phy appears un-documented -- check ./Documentation/devicetree/bindings/ #711: FILE: drivers/phy/phy-exynos5-usbdrd.c:519: + .compatible = samsung,exynos5420-usbdrd-phy,. I think you just need to separate the Documentation into a separate patch before applying the driver patch. I somehow don't see the Documentation warning. Below is the checkpatch output which i ran on this v8 patch version. linux-phy$ ./scripts/checkpatch.pl phy.patch WARNING: please write a paragraph that describes the config symbol fully #127: FILE: drivers/phy/Kconfig:163: +config PHY_EXYNOS5_USBDRD total: 0 errors, 1 warnings, 760 lines checked phy.patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. am i missing something ? [snip] -- Best Regards Vivek Gautam Samsung RD 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 v8 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Hi, On Tuesday 13 May 2014 11:37 AM, Vivek Gautam wrote: Hi Kishon, On Mon, May 12, 2014 at 6:33 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi Gautam, On Friday 09 May 2014 07:27 PM, Vivek Gautam wrote: Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. The new driver uses the generic PHY framework and will interact with DWC3 controller present on Exynos5 series of SoCs. Also, created a new header file in linux/mfd/syscon/ for Exynos5 SoCs and put the required PMU offset definitions for the basic available PHYs. I get the following checkpatch warnings WARNING: please write a paragraph that describes the config symbol fully #163: FILE: drivers/phy/Kconfig:163: +config PHY_EXYNOS5_USBDRD WARNING: DT compatible string samsung,exynos5250-usbdrd-phy appears un-documented -- check ./Documentation/devicetree/bindings/ #708: FILE: drivers/phy/phy-exynos5-usbdrd.c:516: + .compatible = samsung,exynos5250-usbdrd-phy, WARNING: DT compatible string samsung,exynos5420-usbdrd-phy appears un-documented -- check ./Documentation/devicetree/bindings/ #711: FILE: drivers/phy/phy-exynos5-usbdrd.c:519: + .compatible = samsung,exynos5420-usbdrd-phy,. I think you just need to separate the Documentation into a separate patch before applying the driver patch. I somehow don't see the Documentation warning. Below is the checkpatch output which i ran on this v8 patch version. linux-phy$ ./scripts/checkpatch.pl phy.patch WARNING: please write a paragraph that describes the config symbol fully #127: FILE: drivers/phy/Kconfig:163: +config PHY_EXYNOS5_USBDRD total: 0 errors, 1 warnings, 760 lines checked phy.patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. am i missing something ? Yeah.. the checkpatch.pl has got updated recently. If you use the latest kernel you should see it. 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: [PATCHv2] mmc: dw_mmc: change to use recommended reset procedure
On Mon, May 12, 2014 at 10:02 PM, Seungwon Jeon tgih@samsung.com wrote:
As I mentioned in previous version, you put all reset stuff in existing
fifo_reset function.
Although databook mentions ciu_reset case for SBE error, it's not obvious
when ciu_reset is needed in other error cases.
If you intend to add some robust error handing, it would be better to make
another function.
The document I have actually doesn't mention error cases, it describes
this procedure as Controller/DMA/FIFO Reset Usage so I believe it is
saying this is the correct procedure in all cases, and based on our
testing it seems to work. I understand the skepticism, as I shared it
initially when I saw this, but based on our experience, this is
correct and it doesn't need to live in a separate function.
Please check my comments below.
On Tue, May 13, 2014, Sonny Rao wrote:
This patch changes the fifo reset code to follow the reset procedure
outlined in the documentation of Synopsys Mobile storage host databook
7.2.13.
v2: Add Generic DMA support
per the documentation, move interrupt clear before wait
make the test for DMA host-use_dma rather than host-using_dma
add proper return values (although it appears no caller checks)
Signed-off-by: Sonny Rao sonny...@chromium.org
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
drivers/mmc/host/dw_mmc.c | 55
++-
drivers/mmc/host/dw_mmc.h | 1 +
2 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 55cd110..aff57e1 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2325,6 +2325,7 @@ static bool dw_mci_ctrl_reset(struct dw_mci *host, u32
reset)
static inline bool dw_mci_fifo_reset(struct dw_mci *host)
{
+ u32 flags = SDMMC_CTRL_RESET | SDMMC_CTRL_FIFO_RESET;
/*
* Reseting generates a block interrupt, hence setting
* the scatter-gather pointer to NULL.
@@ -2334,7 +2335,59 @@ static inline bool dw_mci_fifo_reset(struct dw_mci
*host)
host-sg = NULL;
}
- return dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET);
+ /*
+ * The recommended method for resetting is to always reset the
+ * controller and the fifo, but differs slightly depending on the mode.
+ * The Generic DMA mode (non IDMAC) also needs to reset DMA where IDMAC
+ * mode resets IDMAC at the end.
+ *
+ */
+#ifndef CONFIG_MMC_DW_IDMAC
Is it added for generic DMA?
IDMAC should be considered for dma_reseet as well.
Please check databook.
Yeah it's a little unclear. In the 7.2.13 Controller/DMA/FIFO Reset
Usage part of the document they mention It is set for what they call
generic DMA, which I think is when there is an external DMA
controller, and the part below that it says for DW-DMA/Non-DW-DMA
that controller_reset and fifo_reset should be set. I believe this
DW-DMA case refers to what is called IDMAC. So, I think it's not
required for this case, but I admit I'm not sure why they also say
Non-DW-DMA. If you know of a good way to differentiate the Generic
DMA case I can implement it. It wasn't clear to me if the driver
even supported this generic dma case, but it sounds like it might,
so I added this code. In practice, on the Exynos Systems we have,
which are using IDMAC, the reset procedure seems to work okay without
the dma_reset bit set, but I cannot test this generic dma case.
The other places in the doc where I see them mention the dma_reset bit
are 7.2.21 Transmission and Reception with Internal DMAC (IDMAC)
and the description of the CTRL register, and in 7.1
Software/Hardware Restrictions where they say it will terminate any
pending transfer.
+ if (host-use_dma)
+ flags |= SDMMC_CTRL_DMA_RESET;
+#endif
+ if (dw_mci_ctrl_reset(host, flags)) {
+ /*
+ * In all cases we clear the RAWINTS register to clear any
+ * interrupts.
+ */
I think interrupt masking is needed before reset because we will not handle
it anymore.
And Is there any reason to move interrupt clear here compared with previous
version?
Yeah I moved it to match the description in the document more closely.
The documents mentioned doing the interrupt clear after setting the
reset bits, and before waiting for the dma_req bit in the status
register to clear. We've been running it with the interrupt clear
below the loop, for a while, and I just tested it with the clear above
the wait to make sure it still works properly and I was able to pass
the tuning process with some errors, so I believe this works fine too,
and more closely matches the description in the doc that I have.
+ mci_writel(host, RINTSTS, 0x);
+
+ /* if using dma we wait for dma_req to clear */
+ if (host-use_dma) {
+ unsigned long timeout =
Re: [PATCH v8 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
On Tue, May 13, 2014 at 12:13 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Tuesday 13 May 2014 11:37 AM, Vivek Gautam wrote: Hi Kishon, On Mon, May 12, 2014 at 6:33 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi Gautam, On Friday 09 May 2014 07:27 PM, Vivek Gautam wrote: Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. The new driver uses the generic PHY framework and will interact with DWC3 controller present on Exynos5 series of SoCs. Also, created a new header file in linux/mfd/syscon/ for Exynos5 SoCs and put the required PMU offset definitions for the basic available PHYs. I get the following checkpatch warnings WARNING: please write a paragraph that describes the config symbol fully #163: FILE: drivers/phy/Kconfig:163: +config PHY_EXYNOS5_USBDRD WARNING: DT compatible string samsung,exynos5250-usbdrd-phy appears un-documented -- check ./Documentation/devicetree/bindings/ #708: FILE: drivers/phy/phy-exynos5-usbdrd.c:516: + .compatible = samsung,exynos5250-usbdrd-phy, WARNING: DT compatible string samsung,exynos5420-usbdrd-phy appears un-documented -- check ./Documentation/devicetree/bindings/ #711: FILE: drivers/phy/phy-exynos5-usbdrd.c:519: + .compatible = samsung,exynos5420-usbdrd-phy,. I think you just need to separate the Documentation into a separate patch before applying the driver patch. I somehow don't see the Documentation warning. Below is the checkpatch output which i ran on this v8 patch version. linux-phy$ ./scripts/checkpatch.pl phy.patch WARNING: please write a paragraph that describes the config symbol fully #127: FILE: drivers/phy/Kconfig:163: +config PHY_EXYNOS5_USBDRD total: 0 errors, 1 warnings, 760 lines checked phy.patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. am i missing something ? Yeah.. the checkpatch.pl has got updated recently. If you use the latest kernel you should see it. right, i can see it now with Torvald's tree. Thanks for pointing out :-) I will move out the Documentation in a separate patch and resubmit. -- Best Regards Vivek Gautam Samsung RD 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 v4 2/2] [media] s5p-mfc: Add support for resolution change event
On 05/13/14 07:59, Arun Kumar K wrote:
From: Pawel Osciak posc...@chromium.org
When a resolution change point is reached, queue an event to signal the
userspace that a new set of buffers is required before decoding can
continue.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |7 +++
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 54f7ba1..2d7d1ae 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -320,6 +320,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
struct s5p_mfc_buf *src_buf;
unsigned long flags;
unsigned int res_change;
+ struct v4l2_event ev;
dst_frame_status = s5p_mfc_hw_call(dev-mfc_ops, get_dspl_status, dev)
S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK;
@@ -351,6 +352,12 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
if (ctx-state == MFCINST_RES_CHANGE_FLUSH) {
s5p_mfc_handle_frame_all_extracted(ctx);
ctx-state = MFCINST_RES_CHANGE_END;
+
+ memset(ev, 0, sizeof(struct v4l2_event));
+ ev.type = V4L2_EVENT_SOURCE_CHANGE;
+ ev.u.src_change.changes = V4L2_EVENT_SRC_CH_RESOLUTION;
I would replace this by:
static const struct v4l2_event ev_src_ch = {
.type = V4L2_EVENT_SOURCE_CHANGE,
.u.src_change.changes = V4L2_EVENT_SRC_CH_RESOLUTION,
};
No need for memsets or filling in structs at runtime.
Regards,
Hans
+ v4l2_event_queue_fh(ctx-fh, ev);
+
goto leave_handle_frame;
} else {
s5p_mfc_handle_frame_all_extracted(ctx);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 4f94491..b383829 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -855,6 +855,8 @@ static int vidioc_subscribe_event(struct v4l2_fh *fh,
switch (sub-type) {
case V4L2_EVENT_EOS:
return v4l2_event_subscribe(fh, sub, 2, NULL);
+ case V4L2_EVENT_SOURCE_CHANGE:
+ return v4l2_src_change_event_subscribe(fh, sub);
default:
return -EINVAL;
}
--
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 v4 1/2] [media] v4l: Add source change event
Hi Arun,
I've got some more comments w.r.t. the documentation:
On 05/13/14 07:59, Arun Kumar K wrote:
This event indicates that the video device has encountered
a source parameter change during runtime. This can typically be a
resolution change detected by a video decoder OR a format change
detected by an HDMI connector.
This needs to be nofified to the userspace and the application may
be expected to reallocate buffers before proceeding. The application
can subscribe to events on a specific pad or input port which
it is interested in.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 32 +
.../DocBook/media/v4l/vidioc-subscribe-event.xml | 19 +++
drivers/media/v4l2-core/v4l2-event.c | 36
include/media/v4l2-event.h |4 +++
include/uapi/linux/videodev2.h |8 +
5 files changed, 99 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index 89891ad..6afabaa 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -242,6 +242,22 @@
/tgroup
/table
+table frame=none pgwide=1 id=v4l2-event-src-change
+ titlestruct structnamev4l2_event_src_change/structname/title
+ tgroup cols=3
+ cs-str;
+ tbody valign=top
+ row
+ entry__u32/entry
+ entrystructfieldchanges/structfield/entry
+ entry
+ A bitmask that tells what has changed. See xref
linkend=src-changes-flags /.
+ /entry
+ /row
+ /tbody
+ /tgroup
+/table
+
table pgwide=1 frame=none id=changes-flags
titleChanges/title
tgroup cols=3
@@ -270,6 +286,22 @@
/tbody
/tgroup
/table
+
+table pgwide=1 frame=none id=src-changes-flags
+ titleSource Changes/title
+ tgroup cols=3
+ cs-def;
+ tbody valign=top
+ row
+ entryconstantV4L2_EVENT_SRC_CH_RESOLUTION/constant/entry
+ entry0x0001/entry
+ entryThis event gets triggered when a resolution change is
+ detected at runtime. This can typically come from a video decoder.
I would rewrite this as:
This event gets triggered when a resolution change is detected at an input.
This can come from an input connector or from a video decoder.
+ /entry
+ /row
+ /tbody
+ /tgroup
+/table
/refsect1
refsect1
return-value;
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 5c70b61..067a0d5 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,25 @@
/entry
/row
row
+ entryconstantV4L2_EVENT_SOURCE_CHANGE/constant/entry
+ entry5/entry
+ entry
+ paraThis event is triggered when a source parameter change is
+detected during runtime by the video device. It can be a
+runtime resolution change triggered by a video decoder or the
+format change happening on an HDMI connector.
s/an HDMI/an input/
It's valid for e.g. a composite input as well (or DVI, or VGA, etc.)
+This event requires that the structfieldid/structfield
+matches the pad / input index from which you want to receive
This should be more explicit:
matches the input index (when used with a video device node) or the pad
index (when used with a subdevice node) from which you want to receive
+events./para
+ paraThis event has a v4l2-event-source-change; associated
+ with it. The structfieldchanges/structfield bitfield denotes
+ what has changed for the subscribed pad. If multiple events
+ occured before application could dequeue them, then the changes
s/occured/occurred/
+ will have the ORed value of all the events generated./para
+ /entry
+ /row
+ row
entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
entry0x0800/entry
entryBase event number for driver-private events./entry
diff --git a/drivers/media/v4l2-core/v4l2-event.c
b/drivers/media/v4l2-core/v4l2-event.c
index 86dcb54..8761aab 100644
--- a/drivers/media/v4l2-core/v4l2-event.c
+++ b/drivers/media/v4l2-core/v4l2-event.c
@@ -318,3 +318,39 @@ int v4l2_event_subdev_unsubscribe(struct v4l2_subdev
*sd, struct v4l2_fh *fh,
return v4l2_event_unsubscribe(fh, sub);
}
EXPORT_SYMBOL_GPL(v4l2_event_subdev_unsubscribe);
+
+static void v4l2_event_src_replace(struct v4l2_event *old,
+ const struct v4l2_event *new)
+{
Re: [RFC V3 2/3] drm/bridge: add a dummy panel driver to support lvds bridges
On Fri, May 09, 2014 at 08:23:01PM +0530, Ajay Kumar wrote:
implement basic panel controls as a drm_bridge so that
the existing bridges can make use of it.
The driver assumes that it is the last entity in the bridge chain.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../bindings/drm/bridge/bridge_panel.txt | 45
Can we please stop adding files to this directory? Device tree bindings
are supposed to be OS agnostic, but DRM is specific to Linux and should
not be used when describing hardware.
diff --git a/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt
b/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt
[...]
+ -led-en-gpio:
+ eDP panel LED enable GPIO.
+ Indicates which GPIO needs to be powered up as output
+ to enable the backlight.
Since this is used to control a backlight, then this should really be a
separate node to describe the backlight device (and use the
corresponding backlight driver) rather than duplicating a subset of that
functionality.
+ -panel-pre-enable-delay:
+ delay value in ms required for panel_pre_enable process
+ Delay in ms needed for the eDP panel LCD unit to
+ powerup, and delay needed between panel_VCC and
+ video_enable.
What are panel_VCC or video_enable?
+ -panel-enable-delay:
+ delay value in ms required for panel_enable process
+ Delay in ms needed for the eDP panel backlight/LED unit
+ to powerup, and delay needed between video_enable and
+ BL_EN.
Similarily, what does BL_EN stand for?
+ bridge-panel {
+ compatible = drm-bridge,panel;
Again, drm- doesn't mean anything outside of Linux (and maybe BSD),
therefore shouldn't be used to describe hardware in device tree.
diff --git a/drivers/gpu/drm/bridge/bridge_panel.c
b/drivers/gpu/drm/bridge/bridge_panel.c
[...]
This duplicates much of the functionality that panels should provide. I
think a better solution would be to properly integrate panels with
bridges.
Thierry
pgpzgMuFL5fKo.pgp
Description: PGP signature
Re: [PATCHv2] mmc: dw_mmc: change to use recommended reset procedure
On Monday 12 May 2014 18:38:41 Sonny Rao wrote: +#ifndef CONFIG_MMC_DW_IDMAC + if (host-use_dma) + flags |= SDMMC_CTRL_DMA_RESET; +#endif Can you change the above like this? if (IS_ENABLED(CONFIG_MMC_DW_IDMAC) host-use_dma) flags |= SDMMC_CTRL_DMA_RESET; That is generally considered the preferred style these days. 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
[PATCH] ARM: dts: Remove g2d_pd node for exynos5420
G2D power domain also controls the CMU block of G2D.
Since clock registers can be accessed anytime for viewing
clk_summary, it can cause a system crash if g2d power domain
is disabled.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Please also refer to the existing discussion on removal of
mau_pd node.
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/29718
This patch also fixes a similar issue of the power domian being
linked to the CMU block. AFAIK, only MAU and G2D power domains
has this problem in 5420.
The issue is more critical now with the merging of following
patches in Tomasz's clk tree -
clk: samsung exynos5250/5420: Add gate clock for SSS module
clk: exynos5420: update clocks for G2D and G3D blocks
With these patches, I get the following crash on kernel booting -
[8.971209] Unhandled fault: imprecise external abort (0x1406) at 0x
[8.993044] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0007
For fixing this, either g2d_pd has to be removed or we need to make all
GATE clocks touching the GATE_IP_G2D as CLK_IGNORE_UNUSED.
I believe removing g2d_pd is the better solution as we get almost the
same power saving by gating off these clocks and keeping the domain ON.
---
arch/arm/boot/dts/exynos5420.dtsi |6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 2f6da50..47d3f17 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -242,11 +242,6 @@
reg = 0x100440E0 0x20;
};
- g2d_pd: power-domain@10044100 {
- compatible = samsung,exynos4210-pd;
- reg = 0x10044100 0x20;
- };
-
msc_pd: power-domain@10044120 {
compatible = samsung,exynos4210-pd;
reg = 0x10044120 0x20;
@@ -755,6 +750,5 @@
interrupts = 0 112 0;
clocks = clock 471;
clock-names = secss;
- samsung,power-domain = g2d_pd;
};
};
--
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 5/6] ARM: EXYNOS: Enable multi-platform build support
On Tuesday 13 May 2014 13:37:33 Kukjin Kim wrote: Arnd Bergmann wrote: On Tuesday 22 April 2014, Olof Johansson wrote: I don't think there's a point in keeping this around. A single-platform config is just enabling a single platform in the config, it's not a specific option. I don't think any of the other platforms use anything like this today. The only one doing that is shmobile, but only because they have some SoCs that are multiplatform capable and some that are not. This isn't the case for Exynos, so it should no longer be needed. When I originally created this patch 18 months ago, there were a number of drivers that broke when multiplatform got enabled. Now the cpufreq driver is the only one left, but it seems that it will make it for 3.16, and I wouldn't wait for it if it doesn't. Let's just do multiplatform-only. In my position in S.LSI, I'd like to keep the current ARCH_EXYNOS4 and EXYNOS5 because IMHO selecting each series would be helpful on real product, multiplatform is available though. Additionally EXYNOS3 is being added. It's true we can support exynos-multiplatform even though above options are included... I think we are talking about different questions here: What Olof and I mean is we don't want to have an ARCH_EXYNOS_SINGLE option that is there for building EXYNOS but not allowing any other SoC. What I think you mean is that you want the individual EXYNOS versions to be separate Kconfig options, so you can build a kernel that supports EXYNOS4 but not EXYNOS5 if you want to. This is totally fine as far as I'm concerned, and it's not directly related to the first point. Note that if you enable LPAE, you will still only be able to build EXYNOS5 after the patch, but then you can have it in the same kernel as e.g. Tegra4 and Snapdragon 600. 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 v2] [media] s5p-mfc: add init buffer cmd to MFCV6
Hi,
From: Arun Kumar K [mailto:arunkk.sams...@gmail.com] On Behalf Of Arun
Kumar K
Sent: Tuesday, March 11, 2014 10:16 AM
From: avnd kiran avnd.ki...@samsung.com
Latest MFC v6 firmware requires tile mode and loop filter setting to be
done as part of Init buffer command, in sync with v7. Since there are
two versions of v6 firmware with different interfaces, it is
differenciated using the version number read back from firmware which
is a hexadecimal value based on the firmware date.
Signed-off-by: avnd kiran avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Changes from v1
---
- Check for v6 firmware date for differenciating old and new firmware
as per comments from Kamil and Sylwester.
---
drivers/media/platform/s5p-mfc/regs-mfc-v6.h|1 +
drivers/media/platform/s5p-mfc/regs-mfc-v7.h|2 --
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |8 +++---
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 30
---
5 files changed, 34 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
index 8d0b686..b47567c 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
@@ -132,6 +132,7 @@
#define S5P_FIMV_D_METADATA_BUFFER_ADDR_V6 0xf448
#define S5P_FIMV_D_METADATA_BUFFER_SIZE_V6 0xf44c
#define S5P_FIMV_D_NUM_MV_V6 0xf478
+#define S5P_FIMV_D_INIT_BUFFER_OPTIONS_V60xf47c
#define S5P_FIMV_D_CPB_BUFFER_ADDR_V60xf4b0
#define S5P_FIMV_D_CPB_BUFFER_SIZE_V60xf4b4
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
index ea5ec2a..82c96fa 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
@@ -18,8 +18,6 @@
#define S5P_FIMV_CODEC_VP8_ENC_V725
/* Additional registers for v7 */
-#define S5P_FIMV_D_INIT_BUFFER_OPTIONS_V70xf47c
-
#define S5P_FIMV_E_SOURCE_FIRST_ADDR_V7 0xf9e0
#define S5P_FIMV_E_SOURCE_SECOND_ADDR_V7 0xf9e4
#define S5P_FIMV_E_SOURCE_THIRD_ADDR_V7 0xf9e8
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 4d17df9..f5404a6 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -287,6 +287,7 @@ struct s5p_mfc_priv_buf {
* @warn_start: hardware error code from which warnings
start
* @mfc_ops: ops structure holding HW operation function
pointers
* @mfc_cmds:cmd structure holding HW commands function
pointers
+ * @ver: firmware sub version
*
*/
struct s5p_mfc_dev {
@@ -330,6 +331,7 @@ struct s5p_mfc_dev {
int warn_start;
struct s5p_mfc_hw_ops *mfc_ops;
struct s5p_mfc_hw_cmds *mfc_cmds;
+ int ver;
};
/**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 2475a3c..ba1d302 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -240,7 +240,6 @@ static inline void s5p_mfc_clear_cmds(struct
s5p_mfc_dev *dev)
/* Initialize hardware */
int s5p_mfc_init_hw(struct s5p_mfc_dev *dev) {
- unsigned int ver;
int ret;
mfc_debug_enter();
@@ -302,12 +301,13 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
return -EIO;
}
if (IS_MFCV6_PLUS(dev))
- ver = mfc_read(dev, S5P_FIMV_FW_VERSION_V6);
+ dev-ver = mfc_read(dev, S5P_FIMV_FW_VERSION_V6);
else
- ver = mfc_read(dev, S5P_FIMV_FW_VERSION);
+ dev-ver = mfc_read(dev, S5P_FIMV_FW_VERSION);
mfc_debug(2, MFC F/W version : %02xyy, %02xmm, %02xdd\n,
- (ver 16) 0xFF, (ver 8) 0xFF, ver 0xFF);
+ (dev-ver 16) 0xFF, (dev-ver 8) 0xFF,
+ dev-ver 0xFF);
s5p_mfc_clock_off();
mfc_debug_leave();
return 0;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 90edb19..356cfe5 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -14,6 +14,7 @@
#undef DEBUG
+#include linux/bcd.h
#include linux/delay.h
#include linux/mm.h
#include linux/io.h
@@ -1269,6 +1270,29 @@ static int s5p_mfc_set_enc_params_vp8(struct
s5p_mfc_ctx *ctx)
return 0;
}
+/* Check if newer v6 firmware with changed init buffer interface */
+static bool s5p_mfc_is_v6_new(struct s5p_mfc_dev *dev) {
+ unsigned long cur_fw, v6_new_fw;
+ unsigned int y, m, d;
+
+
Re: [PATCH v2] [media] s5p-mfc: add init buffer cmd to MFCV6
Hi Kamil,
On Tue, May 13, 2014 at 2:49 PM, Kamil Debski k.deb...@samsung.com wrote:
Hi,
From: Arun Kumar K [mailto:arunkk.sams...@gmail.com] On Behalf Of Arun
Kumar K
Sent: Tuesday, March 11, 2014 10:16 AM
From: avnd kiran avnd.ki...@samsung.com
Latest MFC v6 firmware requires tile mode and loop filter setting to be
done as part of Init buffer command, in sync with v7. Since there are
two versions of v6 firmware with different interfaces, it is
differenciated using the version number read back from firmware which
is a hexadecimal value based on the firmware date.
Signed-off-by: avnd kiran avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Changes from v1
---
- Check for v6 firmware date for differenciating old and new firmware
as per comments from Kamil and Sylwester.
---
drivers/media/platform/s5p-mfc/regs-mfc-v6.h|1 +
drivers/media/platform/s5p-mfc/regs-mfc-v7.h|2 --
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |8 +++---
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 30
---
5 files changed, 34 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
index 8d0b686..b47567c 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
@@ -132,6 +132,7 @@
#define S5P_FIMV_D_METADATA_BUFFER_ADDR_V6 0xf448
#define S5P_FIMV_D_METADATA_BUFFER_SIZE_V6 0xf44c
#define S5P_FIMV_D_NUM_MV_V6 0xf478
+#define S5P_FIMV_D_INIT_BUFFER_OPTIONS_V60xf47c
#define S5P_FIMV_D_CPB_BUFFER_ADDR_V60xf4b0
#define S5P_FIMV_D_CPB_BUFFER_SIZE_V60xf4b4
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
index ea5ec2a..82c96fa 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
@@ -18,8 +18,6 @@
#define S5P_FIMV_CODEC_VP8_ENC_V725
/* Additional registers for v7 */
-#define S5P_FIMV_D_INIT_BUFFER_OPTIONS_V70xf47c
-
#define S5P_FIMV_E_SOURCE_FIRST_ADDR_V7 0xf9e0
#define S5P_FIMV_E_SOURCE_SECOND_ADDR_V7 0xf9e4
#define S5P_FIMV_E_SOURCE_THIRD_ADDR_V7 0xf9e8
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 4d17df9..f5404a6 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -287,6 +287,7 @@ struct s5p_mfc_priv_buf {
* @warn_start: hardware error code from which warnings
start
* @mfc_ops: ops structure holding HW operation function
pointers
* @mfc_cmds:cmd structure holding HW commands function
pointers
+ * @ver: firmware sub version
*
*/
struct s5p_mfc_dev {
@@ -330,6 +331,7 @@ struct s5p_mfc_dev {
int warn_start;
struct s5p_mfc_hw_ops *mfc_ops;
struct s5p_mfc_hw_cmds *mfc_cmds;
+ int ver;
};
/**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 2475a3c..ba1d302 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -240,7 +240,6 @@ static inline void s5p_mfc_clear_cmds(struct
s5p_mfc_dev *dev)
/* Initialize hardware */
int s5p_mfc_init_hw(struct s5p_mfc_dev *dev) {
- unsigned int ver;
int ret;
mfc_debug_enter();
@@ -302,12 +301,13 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
return -EIO;
}
if (IS_MFCV6_PLUS(dev))
- ver = mfc_read(dev, S5P_FIMV_FW_VERSION_V6);
+ dev-ver = mfc_read(dev, S5P_FIMV_FW_VERSION_V6);
else
- ver = mfc_read(dev, S5P_FIMV_FW_VERSION);
+ dev-ver = mfc_read(dev, S5P_FIMV_FW_VERSION);
mfc_debug(2, MFC F/W version : %02xyy, %02xmm, %02xdd\n,
- (ver 16) 0xFF, (ver 8) 0xFF, ver 0xFF);
+ (dev-ver 16) 0xFF, (dev-ver 8) 0xFF,
+ dev-ver 0xFF);
s5p_mfc_clock_off();
mfc_debug_leave();
return 0;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 90edb19..356cfe5 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -14,6 +14,7 @@
#undef DEBUG
+#include linux/bcd.h
#include linux/delay.h
#include linux/mm.h
#include linux/io.h
@@ -1269,6 +1270,29 @@ static int s5p_mfc_set_enc_params_vp8(struct
s5p_mfc_ctx *ctx)
return 0;
}
+/* Check if newer v6 firmware with changed init buffer interface */
+static bool s5p_mfc_is_v6_new(struct s5p_mfc_dev *dev) {
+
[PATCH v9 3/3] phy: exynos5-usbdrd: Add facility for VBUS supply
Adding support to enable/disable VBUS controlled by a
regulator, to enable vbus supply on the port.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/phy/phy-exynos5-usbdrd.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 8fcdd94..76d862b 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -24,6 +24,7 @@
#include linux/mfd/syscon.h
#include linux/mfd/syscon/exynos5-pmu.h
#include linux/regmap.h
+#include linux/regulator/consumer.h
/* Exynos USB PHY registers */
#define EXYNOS5_FSEL_9MHZ6 0x0
@@ -170,6 +171,7 @@ struct exynos5_usbdrd_phy {
} phys[EXYNOS5_DRDPHYS_NUM];
u32 extrefclk;
struct clk *ref_clk;
+ struct regulator *vbus;
};
static inline
@@ -438,6 +440,7 @@ static int exynos5_usbdrd_phy_exit(struct phy *phy)
static int exynos5_usbdrd_phy_power_on(struct phy *phy)
{
+ int ret;
struct phy_usb_instance *inst = phy_get_drvdata(phy);
struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
@@ -445,10 +448,24 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
clk_prepare_enable(phy_drd-ref_clk);
+ /* Enable VBUS supply */
+ if (phy_drd-vbus) {
+ ret = regulator_enable(phy_drd-vbus);
+ if (ret) {
+ dev_err(phy_drd-dev, Failed to enable VBUS supply\n);
+ goto fail_vbus;
+ }
+ }
+
/* Power-on PHY*/
inst-phy_cfg-phy_isol(inst, 0);
return 0;
+
+fail_vbus:
+ clk_disable_unprepare(phy_drd-ref_clk);
+
+ return ret;
}
static int exynos5_usbdrd_phy_power_off(struct phy *phy)
@@ -461,6 +478,10 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
/* Power-off the PHY */
inst-phy_cfg-phy_isol(inst, 1);
+ /* Disable VBUS supply */
+ if (phy_drd-vbus)
+ regulator_disable(phy_drd-vbus);
+
clk_disable_unprepare(phy_drd-ref_clk);
return 0;
@@ -600,6 +621,17 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
break;
}
+ /* Get Vbus regulator */
+ phy_drd-vbus = devm_regulator_get(dev, vbus);
+ if (IS_ERR(phy_drd-vbus)) {
+ ret = PTR_ERR(phy_drd-vbus);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ dev_warn(dev, Failed to get VBUS supply regulator\n);
+ phy_drd-vbus = NULL;
+ }
+
dev_vdbg(dev, Creating usbdrd_phy phy\n);
for (i = 0; i EXYNOS5_DRDPHYS_NUM; i++) {
--
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
[PATCH v9 2/3] phy: Add new Exynos5 USB 3.0 PHY driver
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. The new driver uses the generic PHY framework and will interact with DWC3 controller present on Exynos5 series of SoCs. Also, created a new header file in linux/mfd/syscon/ for Exynos5 SoCs and put the required PMU offset definitions for the basic available PHYs. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/phy/Kconfig| 11 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos5-usbdrd.c | 644 include/linux/mfd/syscon/exynos5-pmu.h | 44 +++ 4 files changed, 700 insertions(+) create mode 100644 drivers/phy/phy-exynos5-usbdrd.c create mode 100644 include/linux/mfd/syscon/exynos5-pmu.h diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 071b763..16a2f06 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -160,6 +160,17 @@ config PHY_EXYNOS5250_USB2 particular SoC is compiled in the driver. In case of Exynos 5250 four phys are available - device, host, HSIC0 and HSIC. +config PHY_EXYNOS5_USBDRD + tristate Exynos5 SoC series USB DRD PHY driver + depends on ARCH_EXYNOS5 OF + depends on HAS_IOMEM + select GENERIC_PHY + select MFD_SYSCON + help + Enable USB DRD PHY support for Exynos 5 SoC series. + This driver provides PHY interface for USB 3.0 DRD controller + present on Exynos5 SoC series. + config PHY_XGENE tristate APM X-Gene 15Gbps PHY support depends on HAS_IOMEM OF (ARM64 || COMPILE_TEST) diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index 7728518..b4f1d57 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -18,4 +18,5 @@ phy-exynos-usb2-y += phy-samsung-usb2.o phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o +obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c new file mode 100644 index 000..8fcdd94 --- /dev/null +++ b/drivers/phy/phy-exynos5-usbdrd.c @@ -0,0 +1,644 @@ +/* + * Samsung EXYNOS5 SoC series USB DRD PHY driver + * + * Phy provider for USB 3.0 DRD controller on Exynos5 SoC series + * + * Copyright (C) 2014 Samsung Electronics Co., Ltd. + * Author: Vivek Gautam gautam.vi...@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/clk.h +#include linux/delay.h +#include linux/io.h +#include linux/kernel.h +#include linux/module.h +#include linux/of.h +#include linux/of_address.h +#include linux/phy/phy.h +#include linux/platform_device.h +#include linux/mutex.h +#include linux/mfd/syscon.h +#include linux/mfd/syscon/exynos5-pmu.h +#include linux/regmap.h + +/* Exynos USB PHY registers */ +#define EXYNOS5_FSEL_9MHZ6 0x0 +#define EXYNOS5_FSEL_10MHZ 0x1 +#define EXYNOS5_FSEL_12MHZ 0x2 +#define EXYNOS5_FSEL_19MHZ20x3 +#define EXYNOS5_FSEL_20MHZ 0x4 +#define EXYNOS5_FSEL_24MHZ 0x5 +#define EXYNOS5_FSEL_50MHZ 0x7 + +/* EXYNOS5: USB 3.0 DRD PHY registers */ +#define EXYNOS5_DRD_LINKSYSTEM 0x04 + +#define LINKSYSTEM_FLADJ_MASK (0x3f 1) +#define LINKSYSTEM_FLADJ(_x) ((_x) 1) +#define LINKSYSTEM_XHCI_VERSION_CONTROLBIT(27) + +#define EXYNOS5_DRD_PHYUTMI0x08 + +#define PHYUTMI_OTGDISABLE BIT(6) +#define PHYUTMI_FORCESUSPEND BIT(1) +#define PHYUTMI_FORCESLEEP BIT(0) + +#define EXYNOS5_DRD_PHYPIPE0x0c + +#define EXYNOS5_DRD_PHYCLKRST 0x10 + +#define PHYCLKRST_EN_UTMISUSPEND BIT(31) + +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff 23) +#define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) 23) + +#define PHYCLKRST_SSC_RANGE_MASK (0x03 21) +#define PHYCLKRST_SSC_RANGE(_x)((_x) 21) + +#define PHYCLKRST_SSC_EN BIT(20) +#define PHYCLKRST_REF_SSP_EN BIT(19) +#define PHYCLKRST_REF_CLKDIV2 BIT(18) + +#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f 11) +#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 11) +#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x32 11) +#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF(0x68 11) +#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF(0x7d 11) +#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 11) + +#define PHYCLKRST_FSEL_UTMI_MASK (0x7 5) +#define
[PATCH v9 0/3] Add Exynos5 USB 3.0 phy driver based on generic PHY framework
Based on 'next' branch of Kishon's phy tree (linux-phy). Changes from v8: - Moved out the bindings documentation for the PHY in a separate patch to avoid checkpatch warnings. Changes from v7: - Providing an **alternative** approach for pmu-offset; instead of getting it from DT, using offset definitions from a header file, and making use of it in the driver. - Using 'aliases' for getting channel numbers for multi-controller PHY, so as to distinguish between the pmu-offsets. - Added a header file in syscon/ for Exynos5 SoC's pmu offset definitions. - Addressed the review comments for nits: -- Changed 'usbdrd_phy_config' structure with 'exynos5_usbdrd_phy_config' and corresponding instance names. Vivek Gautam (3): Documentation: Document Exynos5 USB 3.0 DRD PHY phy: Add new Exynos5 USB 3.0 PHY driver phy: exynos5-usbdrd: Add facility for VBUS supply .../devicetree/bindings/phy/samsung-phy.txt| 47 ++ drivers/phy/Kconfig| 11 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos5-usbdrd.c | 676 include/linux/mfd/syscon/exynos5-pmu.h | 44 ++ 5 files changed, 779 insertions(+) create mode 100644 drivers/phy/phy-exynos5-usbdrd.c create mode 100644 include/linux/mfd/syscon/exynos5-pmu.h -- 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
[PATCH v9 1/3] Documentation: Document Exynos5 USB 3.0 DRD PHY
Add necessary binding documentation for USB 3.0 DRD PHY present on
Exynos5 SoC series.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 47
1 file changed, 47 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38..2049261 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,50 @@ Example:
compatible = samsung,exynos-sataphy-i2c;
reg = 0x38;
};
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
+ - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+ - ref: PHY's reference clock (usually crystal clock), used for
+ PHY operations, associated by phy name. It is used to
+ determine bit values for clock settings register.
+ For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+- 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 1;
+
+For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usbdrd_phy: usbphy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock 286, clock 1;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
+ #phy-cells = 1;
+ };
+
+- aliases: For SoCs like Exynos5420 having multiple USB 3.0 DRD PHY
controllers,
+ 'usbdrd_phy' nodes should have numbered alias in the aliases node,
+ in the form of usbdrdphyN, N = 0, 1... (depending on number of
+ controllers).
+Example:
+ aliases {
+ usbdrdphy0 = usb3_phy0;
+ usbdrdphy1 = usb3_phy1;
+ };
--
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 v3 1/2] ARM: EXYNOS: Map SYSRAM through generic SRAM bindings
Kukjin, On Tue, 2014-05-13 at 12:12 +0900, Kukjin Kim wrote: Tomasz Figa wrote: You mean s/sram/sysram/ in compatible strings of Exynos-specific reserved areas? If yes, I'm fine, it might be even better. Just remember to update documentation in patch 2/2 as well. Done. If any problems in my tree, please let me know. It seems this one just hit linux-next (in next-20140513) as ARM: EXYNOS: Map SYSRAM through generic DT bindings. Its commit now contains this hunk: --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -843,6 +843,7 @@ config ARCH_EXYNOS select HAVE_S3C_RTC if RTC_CLASS select NEED_MACH_MEMORY_H select SPARSE_IRQ + select SYSRAM select USE_OF help Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5) But there's no Kconfig symbol SYSRAM. However, there is a Kconfig symbol SRAM. Did you perhaps do one s/sram/sysram/ too many on the original patch? Paul Bolle -- 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 v5 1/5] ARM: EXYNOS: Add generic cpu power control functions for all exynos based SoCs
Hi Kukjin,
On Tue, May 13, 2014 at 7:54 AM, Kukjin Kim kgene@samsung.com wrote:
Abhilash Kesavan wrote:
+ Jonghwan Choi, Seungkon Hwang
From: Leela Krishna Amudala leela.kris...@linaro.org
Add generic cpu power control functions for exynos based SoCS
for cpu power up/down and to know the cpu status.
Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
In this case, Abhilash's signed-off-by should be added here.
Will add.
---
arch/arm/mach-exynos/common.h |3 +++
arch/arm/mach-exynos/pm.c | 36
arch/arm/mach-exynos/regs-pmu.h |6 ++
3 files changed, 45 insertions(+)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 47cbab0..a7dbb5f 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -63,5 +63,8 @@ struct exynos_pmu_conf {
};
extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+extern void exynos_cpu_powerdown(int cpu);
IMO, using 'xxx_power_down' would be better.
Will change.
+extern void exynos_cpu_powerup(int cpu);
+extern int exynos_cpu_power_state(int cpu);
Hmm...is it really 'cpu' related? Or 'core' related? As I know, when the
function is called, ARM core and L1 cache will be power_up/down except L2
cache...But I have no strong objection to use 'cpu' here
OK, I am keeping cpu as it is then.
#endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 15af0ce..6651028 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -100,6 +100,42 @@ static int exynos_irq_set_wake(struct irq_data *data,
unsigned int state)
return -ENOENT;
}
+/**
+ * exynos_cpu_powerdown : power down the specified cpu
+ * @cpu : the cpu to power down
+ *
+ * Power downs the specified cpu. The sequence must be finished by a
+ * call to cpu_do_idle()
+ *
+ */
+void exynos_cpu_powerdown(int cpu)
+{
+ __raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+}
+
+/**
+ * exynos_cpu_powerup : power up the specified cpu
+ * @cpu : the cpu to power up
+ *
+ * Power up the specified cpu
+ */
+void exynos_cpu_powerup(int cpu)
+{
+ __raw_writel(S5P_CORE_LOCAL_PWR_EN,
+ EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+}
+
+/**
+ * exynos_cpu_power_state : returns the power state of the cpu
+ * @cpu : the cpu to retrieve the power state from
+ *
+ */
+int exynos_cpu_power_state(int cpu)
+{
+ return (__raw_readl(EXYNOS_ARM_CORE_STATUS(cpu))
+ S5P_CORE_LOCAL_PWR_EN);
+}
+
/* For Cortex-A9 Diagnostic and Power control register */
static unsigned int save_arm_register[2];
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-
pmu.h
index 4f6a256..0bdfcbc 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -121,6 +121,12 @@
#define S5P_CHECK_SLEEP 0x0BAD
+#define EXYNOS_ARM_CORE0_CONFIGURATION S5P_PMUREG(0x2000)
This can be put in order of address.
OK, will fix.
+#define EXYNOS_ARM_CORE_CONFIGURATION(_nr) \
+ (EXYNOS_ARM_CORE0_CONFIGURATION + (0x80 * (_nr)))
+#define EXYNOS_ARM_CORE_STATUS(_nr) \
+ (EXYNOS_ARM_CORE_CONFIGURATION(_nr) + 0x4)
Can you please cleanup codes following definitions are used with using above
definitions?
S5P_ARM_CORE1_CONFIGURATION and S5P_ARM_CORE1_STATUS in hotplug.c and
platsmp.c
Will remove these.
Regards,
Abhilash
+
/* Only for EXYNOS4210 */
#define S5P_CMU_CLKSTOP_LCD1_LOWPWR S5P_PMUREG(0x1154)
#define S5P_CMU_RESET_LCD1_LOWPWRS5P_PMUREG(0x1174)
--
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 v5 2/5] ARM: EXYNOS: use generic exynos cpu power control functions
Hi Kukjin,
On Tue, May 13, 2014 at 7:58 AM, Kukjin Kim kgene@samsung.com wrote:
Abhilash Kesavan wrote:
From: Leela Krishna Amudala leela.kris...@linaro.org
Use generic exynos cpu power control functions to power up/down
and to know the status of the cpu.
Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
Same as previous comment.
---
arch/arm/mach-exynos/platsmp.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-
exynos/platsmp.c
index 0aac032..d442a66 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -130,15 +130,12 @@ static int exynos_boot_secondary(unsigned int cpu,
struct task_struct *idle)
*/
write_pen_release(phys_cpu);
- if (!(__raw_readl(S5P_ARM_CORE1_STATUS) S5P_CORE_LOCAL_PWR_EN)) {
- __raw_writel(S5P_CORE_LOCAL_PWR_EN,
- S5P_ARM_CORE1_CONFIGURATION);
-
+ if (!exynos_cpu_power_state(cpu)) {
+ exynos_cpu_powerup(cpu);
timeout = 10;
/* wait max 10 ms until cpu1 is on */
- while ((__raw_readl(S5P_ARM_CORE1_STATUS)
- S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN) {
+ while (exynos_cpu_power_state(cpu) != S5P_CORE_LOCAL_PWR_EN)
{
if (timeout-- == 0)
break;
--
You may cleanup the definitions of 'S5P_ARM_CORE1_CONFIGURATION/STATUS' in
regs-pmu.h once hotplug.c uses the generic power control functions.
OK, will re-post a new version rebased on your for-next branch soon.
Regards,
Abhilash
- 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 V3 2/3] ARM: EXYNOS5: Add Suspend-to-RAM support for 5420
Hi Bartlomiej,
[...]
- regmap_write(pmu_regmap, S5P_PAD_RET_MAUDIO_OPTION, (1 28));
- regmap_write(pmu_regmap, S5P_PAD_RET_GPIO_OPTION, (1 28));
- regmap_write(pmu_regmap, S5P_PAD_RET_UART_OPTION, (1 28));
- regmap_write(pmu_regmap, S5P_PAD_RET_MMCA_OPTION, (1 28));
- regmap_write(pmu_regmap, S5P_PAD_RET_MMCB_OPTION, (1 28));
- regmap_write(pmu_regmap, S5P_PAD_RET_EBIA_OPTION, (1 28));
- regmap_write(pmu_regmap, S5P_PAD_RET_EBIB_OPTION, (1 28));
+ if (soc_is_exynos5250()) {
Adding a check here for EXYNOS5250 doesn't look correct (the old code
behavior for older EXYNOS SoCs should be preserved).
Will fix this in the next version.
Regards,
Abhilash
--
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 2/3] ARM: EXYNOS5: Add Suspend-to-RAM support for 5420
Hi Pankaj, [...] +#define EXYNOS5420_VA_CPU_STATE (S5P_VA_SYSRAM + 0x28) +#define EXYNOS5420_VA_CPU_ADDR (S5P_VA_SYSRAM_NS + 0x1C) + It will be good if we can rebase this change on top of Sachin's SYSRAM patches [1] [1]: http://www.spinics.net/lists/arm-kernel/msg329188.html This is now merged in Kukjin's for-next. Have rebased my patches on top of it. [...] + + unsigned i; + + s3c_pm_do_save(exynos5420_reg_save, + ARRAY_SIZE(exynos5420_reg_save)); + Is it possible to move this code in DISP driver somewhere? As if you see I have already posted some patches [1] to remove i2c SYS CFG register configuration during S2R from pm.c to i2c driver itself for Exynos5250 as suggested by Arnd. This way we can reduce dependency of regs-sys.h in pm.c also we do not need to statically map sysreg register in exynos.c, and in general it will us in cleaning up exynos code from such things as it is being discussed here [2] [1]: https://lkml.org/lkml/2014/5/6/104 [2]: https://lkml.org/lkml/2014/5/6/71 Will remove. [...] /* For EXYNOS5 */ +#define EXYNOS5_SYS_DISP1_BLK_CFG S5P_SYSREG(0x0214) I think this offset should not be added here as it does not belong with PMU. Moreover IIRC if you have rebased these patches on my Exynos PMU patch series [1], this change should fail to compile as regs-pmu.h does not have anymore mach/map.h and definition for S5P_SYSREG has been moved to a new file regs-sys.h. Please check here [2] [1]: https://lkml.org/lkml/2014/5/2/612 [2]: https://lkml.org/lkml/2014/4/30/8 Will remove. #define EXYNOS5_AUTO_WDTRESET_DISABLE (0x0408) #define EXYNOS5_MASK_WDTRESET_REQUEST (0x040C) -- Best Regards, Pankaj Dubey ___ 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
Re: [PATCH V3 1/3] ARM: EXYNOS5: PMU support for 5420
Hi Alim, [...] + /* Time taken to stabilized XXTI clock */ + regmap_write(pmu_context-pmu_regmap, EXYNOS5_XXTI_DURATION3, 0x005dc); + There is no good reason why XXTI_DURATION3 need to be set here. This is something that iROM sets, please remove this. Will remove. Regards, Abhilash -- 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] ARM: EXYNOS5: PMU support for 5420
Hi Pankaj,
[...]
#include exynos-pmu.h
#include regs-pmu.h
+#include common.h
I think it will be better if we move EXYNOS5420_USE_STANDBY_WFI_ALL
macro into regs-pmu.h itself. It will help us removing dependency of
common.h
from pmu.c, so that in future we can easily move this file out of machine
directory.
Will move to regs-pmu.h
[...]
+ * exynos_set_core_flag - set the cluster id to IROM register
+ * to ensure that we wake up with the
+ * current cluster.
+ */
+static void exynos5420_set_core_flag(void)
+{
+ unsigned int this_cluster;
+ this_cluster = MPIDR_AFFINITY_LEVEL(read_cpuid_mpidr(), 1);
+
+ regmap_write(pmu_context-pmu_regmap, EXYNOS_IROM_DATA2,
this_cluster);
+}
+
+void exynos5420_powerdown_conf(enum sys_powerdown mode)
+{
+ exynos5420_set_core_flag();
I think we can avoid extra function call of exynos5420_set_core_flag by
moving
all of it's code in powerdown_conf itself.
Will move to powerdown_conf.
+}
void exynos5_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
@@ -429,6 +670,80 @@ static void exynos5250_pmu_init(void)
regmap_write(pmu_regmap, EXYNOS5_MASK_WDTRESET_REQUEST, tmp);
}
+static void exynos5420_pmu_init(void)
+{
+ unsigned int value;
+ int i;
+
+ /*
+* Set the CMU_RESET, CMU_SYSCLK and CMU_CLKSTOP registers
+* for local power blocks to Low initially as per Table 8-4:
+* System-Level Power-Down Configuration Registers.
+*/
+ for (i = 0; i ARRAY_SIZE(exynos5420_list_disable_pmu_reg); i++)
+ regmap_write(pmu_context-pmu_regmap,
+ exynos5420_list_disable_pmu_reg[i], 0);
+
+ /* Time taken to stabilized XXTI clock */
+ regmap_write(pmu_context-pmu_regmap, EXYNOS5_XXTI_DURATION3,
0x005dc);
Isn't it will be good if you use some macro of 0x005dc?
Will remove this as per Alim's comment.
Regards,
Abhilash
--
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] mmc: dw_mmc: change to use recommended reset procedure
Hi, On 12/05/14 22:44, Sonny Rao wrote: Doug mentioned that James Hogan might have an answer. James, are there Imgtec SoCs which use dw_mmc and use DMA but don't use the IDMAC? If so, we can add that support into this reset procedure patch. Yes, the Toumaz TZ1090 SoC has the dw_mmc configured without an IDMAC, so it uses the IMG DMAC block instead. Cheers James -- 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 v4 2/2] [media] s5p-mfc: Add support for resolution change event
Hi Hans,
On Tue, May 13, 2014 at 1:29 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On 05/13/14 07:59, Arun Kumar K wrote:
From: Pawel Osciak posc...@chromium.org
When a resolution change point is reached, queue an event to signal the
userspace that a new set of buffers is required before decoding can
continue.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |7 +++
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 54f7ba1..2d7d1ae 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -320,6 +320,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
struct s5p_mfc_buf *src_buf;
unsigned long flags;
unsigned int res_change;
+ struct v4l2_event ev;
dst_frame_status = s5p_mfc_hw_call(dev-mfc_ops, get_dspl_status, dev)
S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK;
@@ -351,6 +352,12 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx
*ctx,
if (ctx-state == MFCINST_RES_CHANGE_FLUSH) {
s5p_mfc_handle_frame_all_extracted(ctx);
ctx-state = MFCINST_RES_CHANGE_END;
+
+ memset(ev, 0, sizeof(struct v4l2_event));
+ ev.type = V4L2_EVENT_SOURCE_CHANGE;
+ ev.u.src_change.changes = V4L2_EVENT_SRC_CH_RESOLUTION;
I would replace this by:
static const struct v4l2_event ev_src_ch = {
.type = V4L2_EVENT_SOURCE_CHANGE,
.u.src_change.changes = V4L2_EVENT_SRC_CH_RESOLUTION,
};
No need for memsets or filling in structs at runtime.
Ok will make this change.
Regards
Arun
Regards,
Hans
+ v4l2_event_queue_fh(ctx-fh, ev);
+
goto leave_handle_frame;
} else {
s5p_mfc_handle_frame_all_extracted(ctx);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 4f94491..b383829 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -855,6 +855,8 @@ static int vidioc_subscribe_event(struct v4l2_fh *fh,
switch (sub-type) {
case V4L2_EVENT_EOS:
return v4l2_event_subscribe(fh, sub, 2, NULL);
+ case V4L2_EVENT_SOURCE_CHANGE:
+ return v4l2_src_change_event_subscribe(fh, sub);
default:
return -EINVAL;
}
--
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 v4 1/2] [media] v4l: Add source change event
Hi Hans, Will make the changes you suggested. Thanks regards Arun On Tue, May 13, 2014 at 1:30 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Arun, I've got some more comments w.r.t. the documentation: On 05/13/14 07:59, Arun Kumar K wrote: This event indicates that the video device has encountered a source parameter change during runtime. This can typically be a resolution change detected by a video decoder OR a format change detected by an HDMI connector. This needs to be nofified to the userspace and the application may be expected to reallocate buffers before proceeding. The application can subscribe to events on a specific pad or input port which it is interested in. Signed-off-by: Arun Kumar K arun...@samsung.com --- Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 32 + .../DocBook/media/v4l/vidioc-subscribe-event.xml | 19 +++ drivers/media/v4l2-core/v4l2-event.c | 36 include/media/v4l2-event.h |4 +++ include/uapi/linux/videodev2.h |8 + 5 files changed, 99 insertions(+) diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 89891ad..6afabaa 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml @@ -242,6 +242,22 @@ /tgroup /table +table frame=none pgwide=1 id=v4l2-event-src-change + titlestruct structnamev4l2_event_src_change/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldchanges/structfield/entry + entry + A bitmask that tells what has changed. See xref linkend=src-changes-flags /. + /entry + /row + /tbody + /tgroup +/table + table pgwide=1 frame=none id=changes-flags titleChanges/title tgroup cols=3 @@ -270,6 +286,22 @@ /tbody /tgroup /table + +table pgwide=1 frame=none id=src-changes-flags + titleSource Changes/title + tgroup cols=3 + cs-def; + tbody valign=top + row + entryconstantV4L2_EVENT_SRC_CH_RESOLUTION/constant/entry + entry0x0001/entry + entryThis event gets triggered when a resolution change is + detected at runtime. This can typically come from a video decoder. I would rewrite this as: This event gets triggered when a resolution change is detected at an input. This can come from an input connector or from a video decoder. + /entry + /row + /tbody + /tgroup +/table /refsect1 refsect1 return-value; diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index 5c70b61..067a0d5 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml @@ -155,6 +155,25 @@ /entry /row row + entryconstantV4L2_EVENT_SOURCE_CHANGE/constant/entry + entry5/entry + entry + paraThis event is triggered when a source parameter change is +detected during runtime by the video device. It can be a +runtime resolution change triggered by a video decoder or the +format change happening on an HDMI connector. s/an HDMI/an input/ It's valid for e.g. a composite input as well (or DVI, or VGA, etc.) +This event requires that the structfieldid/structfield +matches the pad / input index from which you want to receive This should be more explicit: matches the input index (when used with a video device node) or the pad index (when used with a subdevice node) from which you want to receive +events./para + paraThis event has a v4l2-event-source-change; associated + with it. The structfieldchanges/structfield bitfield denotes + what has changed for the subscribed pad. If multiple events + occured before application could dequeue them, then the changes s/occured/occurred/ + will have the ORed value of all the events generated./para + /entry + /row + row entryconstantV4L2_EVENT_PRIVATE_START/constant/entry entry0x0800/entry entryBase event number for driver-private events./entry diff --git a/drivers/media/v4l2-core/v4l2-event.c b/drivers/media/v4l2-core/v4l2-event.c index 86dcb54..8761aab 100644 --- a/drivers/media/v4l2-core/v4l2-event.c +++ b/drivers/media/v4l2-core/v4l2-event.c @@ -318,3 +318,39 @@ int v4l2_event_subdev_unsubscribe(struct v4l2_subdev *sd, struct v4l2_fh *fh, return v4l2_event_unsubscribe(fh, sub); }
RE: [PATCHv2] mmc: dw_mmc: change to use recommended reset procedure
On Tuesday, May 13, Sonny Rao wrote:
On Mon, May 12, 2014 at 10:02 PM, Seungwon Jeon tgih@samsung.com wrote:
As I mentioned in previous version, you put all reset stuff in existing
fifo_reset function.
Although databook mentions ciu_reset case for SBE error, it's not obvious
when ciu_reset is needed
in other error cases.
If you intend to add some robust error handing, it would be better to make
another function.
The document I have actually doesn't mention error cases, it describes
this procedure as Controller/DMA/FIFO Reset Usage so I believe it is
saying this is the correct procedure in all cases, and based on our
testing it seems to work. I understand the skepticism, as I shared it
initially when I saw this, but based on our experience, this is
correct and it doesn't need to live in a separate function.
I agree this active error handling.
But, existing fifo_reset function is focused on fifo reset purely.
I think your change is close to error recovery and it seems overloaded to basic
function.
So, you suggest renaming function for new sequence.
And look into dw_mci_work_routine_card(). dw_mci_idmac_reset() is redundancy.
I expect it can be cleaned.
Quot
/* Clear down the FIFO */
dw_mci_fifo_reset(host);
#ifdef CONFIG_MMC_DW_IDMAC
dw_mci_idmac_reset(host);
#endif
/Quot
Please check my comments below.
On Tue, May 13, 2014, Sonny Rao wrote:
This patch changes the fifo reset code to follow the reset procedure
outlined in the documentation of Synopsys Mobile storage host databook
7.2.13.
Please remove this section number.
No needed. It's old version.
v2: Add Generic DMA support
per the documentation, move interrupt clear before wait
make the test for DMA host-use_dma rather than host-using_dma
add proper return values (although it appears no caller checks)
Signed-off-by: Sonny Rao sonny...@chromium.org
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
drivers/mmc/host/dw_mmc.c | 55
++-
drivers/mmc/host/dw_mmc.h | 1 +
2 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 55cd110..aff57e1 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2325,6 +2325,7 @@ static bool dw_mci_ctrl_reset(struct dw_mci *host,
u32 reset)
static inline bool dw_mci_fifo_reset(struct dw_mci *host)
{
+ u32 flags = SDMMC_CTRL_RESET | SDMMC_CTRL_FIFO_RESET;
/*
* Reseting generates a block interrupt, hence setting
* the scatter-gather pointer to NULL.
@@ -2334,7 +2335,59 @@ static inline bool dw_mci_fifo_reset(struct dw_mci
*host)
host-sg = NULL;
}
- return dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET);
+ /*
+ * The recommended method for resetting is to always reset the
+ * controller and the fifo, but differs slightly depending on the
mode.
+ * The Generic DMA mode (non IDMAC) also needs to reset DMA where
IDMAC
+ * mode resets IDMAC at the end.
+ *
+ */
+#ifndef CONFIG_MMC_DW_IDMAC
Is it added for generic DMA?
IDMAC should be considered for dma_reseet as well.
Please check databook.
Yeah it's a little unclear. In the 7.2.13 Controller/DMA/FIFO Reset
Usage part of the document they mention It is set for what they call
generic DMA, which I think is when there is an external DMA
controller, and the part below that it says for DW-DMA/Non-DW-DMA
that controller_reset and fifo_reset should be set. I believe this
DW-DMA case refers to what is called IDMAC. So, I think it's not
required for this case, but I admit I'm not sure why they also say
Non-DW-DMA. If you know of a good way to differentiate the Generic
DMA case I can implement it. It wasn't clear to me if the driver
even supported this generic dma case, but it sounds like it might,
so I added this code. In practice, on the Exynos Systems we have,
which are using IDMAC, the reset procedure seems to work okay without
the dma_reset bit set, but I cannot test this generic dma case.
The other places in the doc where I see them mention the dma_reset bit
are 7.2.21 Transmission and Reception with Internal DMAC (IDMAC)
and the description of the CTRL register, and in 7.1
Software/Hardware Restrictions where they say it will terminate any
pending transfer.
DW-DMA means Synopsys's DMA controller not IDMAC.
SDMMC_CTRL_DMA_RESET can apply in all type DMA interface.
+ if (host-use_dma)
+ flags |= SDMMC_CTRL_DMA_RESET;
+#endif
+ if (dw_mci_ctrl_reset(host, flags)) {
+ /*
+ * In all cases we clear the RAWINTS register to clear any
+ * interrupts.
+ */
I think interrupt masking is needed before reset
Re: [RFC V2 0/3] drm/bridge: panel and chaining
On 05/12/2014 02:45 PM, Rob Clark wrote:
On Mon, May 12, 2014 at 3:06 AM, Andrzej Hajda a.ha...@samsung.com wrote:
On 05/09/2014 05:05 PM, Ajay kumar wrote:
On Fri, May 9, 2014 at 7:29 PM, Rob Clark robdcl...@gmail.com wrote:
On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda a.ha...@samsung.com wrote:
On 05/08/2014 08:24 PM, Rob Clark wrote:
On Thu, May 8, 2014 at 2:41 AM, Andrzej Hajda a.ha...@samsung.com
wrote:
On 05/05/2014 09:52 PM, Ajay Kumar wrote:
This patchset is based on exynos-drm-next-todo branch of Inki Dae's
tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have just put up Rob's and Sean's idea of chaining up the bridges
in code, and have implemented basic panel controls as a chained bridge.
This works well with ptn3460 bridge chip on exynos5250-snow board.
Still need to make use of standard list calls and figure out proper way
of deleting the bridge chain. So, this is just a rough version.
As I understand this patchset tries to solve two things:
1. Implement panel as drm_bridge, to ease support for hardware chains:
Crtc - Encoder - Bridge - Panel
2. Add support to drm_bridge chaining, to allow software chains:
drm_crtc - drm_encoder - drm_bridge - drm_bridge,panel
It is done using Russian doll schema, ops from the bridge calls the same
ops from the next bridge and the next bridge ops can do the same.
This schema means that all the bridges including the last one are seen
from the drm core point of view as a one big drm_bridge. Additionally in
this particular case, the first bridge (ptn3460) implements connector
so it is hard to guess what is the location of the 2nd bridge in video
stream chain, sometimes it is after the connector, sometimes before.
All this is quite confusing.
But if you look at the bridge from upstream video interface point of
view it is just a panel, edp panel in case of ptn3460, ie ptn3460 on its
video input side acts as a panel. On the output side it expects a panel,
lvds panel in this case.
tbh, this is mostly about what we call it. Perhaps bridge isn't the
best name.. I wouldn't object to changing it.
But my thinking was to leave in drm_panel_funcs things that are just
needed by the connector (get_modes().. and maybe some day we need
detect/etc). Then leave everything else in drm_bridge_funcs. A panel
could (if needed) implement both interfaces.
That is basically the same as what you are proposing, but without
renaming bridge to panel ;-)
Good to hear that. However there are points which are not clear for me.
But first lets clarify names, I will use panel and bridge words
to describe the hardware, and drm_panel, drm_bridge to describe the
software interfaces.
What bothers me:
1. You want to leave connector related callbacks in drm_panel and
the rest in drm_bridge. In case of ptn3460 it does not work, ptn3460
must implement connector internally because of this limitation. I guess
it is quite typical bridge. This problem does not exists in case
of using drm_panel for ptn3460.
2. drm_bridge is attached to the encoder, this and the callback order
suggests the video data flow should be as below:
drm_crtc - drm_encoder [- drm_bridge] - drm_connector [- drm_panel]
ptn3460 implements drm_bridge and drm_connector so it suggests its
drm_bridge should be the last one, so there should be no place to add
lvds panel implemented as a drm_bridge after it, as it is done in this
patchset.
Additionally it clearly shows that there should be two categories of
drm_bridges - non-terminal and terminal.
3. drm_dev uses all-or-nothing approach, ie. it will start only when all
its components are up. It simplifies synchronization but is quite
fragile - the whole drm will be down due to error in some of its
components.
For this reason I prefer drm_panel as it is not real drm component
it can be attached/detached to/from drm_connector anytime. I am not
really sure but drm_bridge does not allow for that.
So I do think we need to stick to this all-or-nothing approach for
anything that is visible to userspace
(drm_{plane,crtc,encoder,connector}). We don't currently have a way
to hotplug those so I don't see a real smooth upgrade path to add
that in a backwards compatible way that won't cause problems with old
userspace.
But, that said, we have more flexibility with things not visible to
userspace (drm_{panel,bridge}). I'm not sure how much we want to
allow things to be completely dynamic (we already have some hard
enough locking fun). But proposals/rfcs/etc welcome.
I guess I'm not completely familiar w/ ptn3460, but the fact that it
needs to implement drm_connector makes me a bit suspicious. Seems
like a symptom of missing things in drm_panel_funcs. It would be
better to always create the connector statically, and just have
_detect() - disconnected if panel==NULL.
ptn3460 has been implemented using drm_bridge and drm_connector, not by
me, to be clear :)
sure, and
Re: [PATCHv2 1/3] phy: Add exynos-simple-phy driver
Gentle PING On 7 May 2014 21:03, Tomasz Figa t.f...@samsung.com wrote: [CCing more DT-folks :)] On 07.05.2014 16:19, Rahul Sharma wrote: On 7 May 2014 19:06, Tomasz Stanislawski t.stanisl...@samsung.com wrote: On 05/07/2014 12:38 PM, Rahul Sharma wrote: On 5 May 2014 15:14, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote: Hi, On 09/04/14 11:12, Rahul Sharma wrote: Idea looks good. How about keeping compatible which is independent of SoC, something like samsung,exynos-simple-phy and provide Reg and Bit through phy provider node. This way we can avoid SoC specific hardcoding in phy driver and don't need to look into dt bindings for each new SoC. I believe it is a not recommended approach. Why not? We should try to avoid hard coding in the driver code. Moreover by avoiding hardcoding we can make it a generic driver for single bit PHYs. +1. @Tomasz, any plans to consider this approach for simple phy driver? Regards, Rahul Sharma. Hi Rahul, Initially, I wanted to make a very generic driver and to add bit and register (or its offset) attribute to the PHY node. However, there was a very strong opposition from DT maintainers to adding any bit related configuration to DT. The current solution was designed to be a trade-off between being generic and being accepted :). Thanks Tomasz, Ok got it. lets discuss it again and conclude it. @Kishon, DT-folks, The original RFC patch from Tomasz (at https://lkml.org/lkml/2013/10/21/313) added simple phy driver as Generic-simple-phy with these properties: + of_property_read_u32(dev-of_node, mask, sphy-mask); + of_property_read_u32(dev-of_node, on-value, sphy-on_value); + of_property_read_u32(dev-of_node, off-value, sphy-off_value); Shall we consider the same solution again for generic simple phy driver which just expose on/off control through register bit. Regards, Rahul Sharma Regards, Tomasz Stanislawski Cheers Kishon ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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, Tomasz ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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/3] [media] s5p-mfc: Add variants to access mfc registers
Hi Kamil,
On 05/13/14 16:02, Kamil Debski wrote:
Hi,
One small comment below,
-Original Message-
From: Arun Kumar K [mailto:arunkk.sams...@gmail.com] On Behalf Of Arun
Kumar K
Sent: Wednesday, April 23, 2014 2:58 PM
To: linux-me...@vger.kernel.org; linux-samsung-soc@vger.kernel.org
Cc: k.deb...@samsung.com; s.nawro...@samsung.com; posc...@chromium.org;
avnd.ki...@samsung.com; arunkk.sams...@gmail.com
Subject: [PATCH 1/3] [media] s5p-mfc: Add variants to access mfc
registers
From: Kiran AVND avnd.ki...@samsung.com
This patch is needed in preparation to add MFC V8
where the register offsets are changed w.r.t MFC V6/V7.
This patch adds variants of MFC V6 and V7 while
accessing MFC registers. Registers are kept in mfc context
and are initialized to a particular MFC variant during probe,
which is used instead of macros.
This avoids duplication of the code for MFC variants
V6 V7, and reduces the if_else checks while accessing
registers of different MFC variants.
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c|1 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
drivers/media/platform/s5p-mfc/s5p_mfc_opr.c|6 +
drivers/media/platform/s5p-mfc/s5p_mfc_opr.h| 254 +
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 697
+++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |7 +-
6 files changed, 710 insertions(+), 256 deletions(-)
[snip]
if (p_h264-fmo) {
@@ -988,10 +991,12 @@ static int s5p_mfc_set_enc_params_h264(struct
s5p_mfc_ctx *ctx)
case V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_INTERLEAVED_SLICES:
if (p_h264-fmo_slice_grp 4)
p_h264-fmo_slice_grp = 4;
-for (i = 0; i (p_h264-fmo_slice_grp 0xF); i++)
+for (i = 0; i ARRAY_SIZE(p_h264-fmo_run_len)
+ i p_h264-fmo_slice_grp; i++) {
What do you think about moving this to separate path? This seems
like it slipped with the register patches.
Sure I will remove this change from this patch. Thanks for spotting this.
Regards
Arun
--
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] [media] s5p-mfc: Dequeue sequence header after STREAMON
Hi Sachin,
Thank you for the review.
Will address your comments and post updated version.
Regards
Arun
On Thu, May 8, 2014 at 3:09 PM, Sachin Kamat sachin.ka...@linaro.org wrote:
Hi Arun,
Just 2 small nits.
On 7 May 2014 17:00, Arun Kumar K arun...@samsung.com wrote:
MFCv6 encoder needs specific minimum number of buffers to
be queued in the CAPTURE plane. This minimum number will
be known only when the sequence header is generated.
So we used to allow STREAMON on the CAPTURE plane only after
sequence header is generated and checked with the minimum
buffer requirement.
But this causes a problem that we call a vb2_buffer_done
for the sequence header buffer before doing a STREAON on the
CAPTURE plane. This used to still work fine until this patch
was merged b3379c6201bb3555298cdbf0aa004af260f2a6a4.
Please provide the patch title too along with commit ID
(first 12 characters of ID is enough).
This problem should also come in earlier MFC firmware versions
if the application calls STREAMON on CAPTURE with some delay
after doing STREAMON on OUTPUT.
So this patch keeps the header buffer until the other frame
buffers are ready and dequeues it just before the first frame
is ready.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|6 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index d64b680..4fd1034 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -523,6 +523,7 @@ struct s5p_mfc_codec_ops {
* @output_state: state of the output buffers queue
* @src_bufs: information on allocated source buffers
* @dst_bufs: information on allocated destination buffers
+ * @header_mb: buf pointer of the encoded sequence header
s/buf/buffer
--
With warm regards,
Sachin
--
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 v4 5/5] mcpm: exynos: populate suspend and powered_up callbacks
Hi Lorenzo
On 9 May 2014 21:02, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote:
On Mon, May 05, 2014 at 10:27:20AM +0100, Chander Kashyap wrote:
In order to support cpuidle through mcpm, suspend and powered-up
callbacks are required in mcpm platform code.
Hence populate the same callbacks.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
Changes in v4: None
Changes in v3:
1. Removed coherancy enablement after suspend failure.
coherency
2. Use generic function to poweron cpu.
changes in v2:
1. Fixed typo: enynos_pmu_cpunr to exynos_pmu_cpunr
arch/arm/mach-exynos/mcpm-exynos.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index d0f7461..6d4a907 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -256,10 +256,44 @@ static int exynos_power_down_finish(unsigned int cpu,
unsigned int cluster)
return -ETIMEDOUT; /* timeout */
}
+void exynos_powered_up(void)
static ?
Ok, done
+{
+ unsigned int mpidr, cpu, cluster;
+
+ mpidr = read_cpuid_mpidr();
+ cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+ arch_spin_lock(exynos_mcpm_lock);
+ if (cpu_use_count[cpu][cluster] == 0)
+ cpu_use_count[cpu][cluster] = 1;
+ arch_spin_unlock(exynos_mcpm_lock);
+}
+
+static void exynos_suspend(u64 residency)
+{
+ unsigned int mpidr, cpunr;
+
+ mpidr = read_cpuid_mpidr();
+ cpunr = exynos_pmu_cpunr(mpidr);
If I were to be picky, I would compute these values only if they
are needed, ie move the computation after exynos_power_down().
Yes thats make sense. I will realign it.
There is another quite horrible issue here. We know this code works
because the processors A15/A7 hit the caches with C bit in SCTLR cleared.
On processors where this is not true, this sequence would explode
if power down fails (in case core is gated but L2 is still powered on,
the stack is stuck in L2) since it is going to read stack data that is
in L2 but can't be read.
It is not related to this sequence only, but it is an issue in general
and wanted to mention that on the lists for public awareness.
Can you please elaborate. I didn't understand.
The gist of what I am saying is, please add a comment to that extent,
here and it should be added in exynos_power_down() too.
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 0x1c);
No magic numbers please (0x1c). You can add a macro/wrapper, as TC2 does.
Yes i will remove it.
+ exynos_power_down();
+
+ /*
+ * Execution reaches here only if cpu did not power down.
+ * Hence roll back the changes done in exynos_power_down function.
+ */
+ exynos_cpu_powerup(cpunr);
Please be aware that if this function returns MCPM will soft reboot, and
the CPUidle driver will have no way to detect a state entry failure.
I am just flagging this up, since fixing this behaviour is not easy, and
honestly, since power down failure should be the exception not the rule,
the idle stats should not be affected much.
I think this is the proper way of implementing the sequence but please
all keep in mind what I wrote above.
Lorenzo
+}
+
static const struct mcpm_platform_ops exynos_power_ops = {
.power_up = exynos_power_up,
.power_down = exynos_power_down,
.power_down_finish = exynos_power_down_finish,
+ .suspend= exynos_suspend,
+ .powered_up = exynos_powered_up,
};
static void __init exynos_mcpm_usage_count_init(void)
--
1.7.9.5
--
with warm regards,
Chander Kashyap
--
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] crypto: s5p-sss: fix multiplatform build
On Mon, May 12, 2014 at 11:31:05AM +0900, Jingoo Han wrote: On Friday, May 09, 2014 8:36 PM, Arnd Bergmann wrote: As we are preparing to enable multiplatform support on EXYNOS, we can no longer include mach/*.h or plat/*.h headers from device drivers. The s5p-sss driver was just enabled for EXYNOS when it used to be used only on s5pv210, and it includes two samsung platform specific header files for historic reasons. Fortunately, it no longer actually needs them, so we can remove the #includes and avoid the problem Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Tomasz Figa t.f...@samsung.com Cc: linux-samsung-soc@vger.kernel.org Cc: Vladimir Zapolskiy v...@mleia.com Cc: Herbert Xu herb...@gondor.apana.org.au I checked that these machine specific headers are unnecessary. Thanks! Reviewed-by: Jingoo Han jg1@samsung.com Patch applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: [PATCHv4 5/7] clk: samsung: exynos3250: Add clocks using common clock framework
Hi Tomasz, On 04/26/2014 09:39 AM, Tomasz Figa wrote: Hi Chanwoo, On 25.04.2014 03:16, Chanwoo Choi wrote: From: Tomasz Figa t.f...@samsung.com This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7 using common clock framework. The CMU (Clock Management Unit) of Exynos3250 control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses, and function clocks for individual IPs. The CMU of Exynos3250 includes following clock doamins: - CPU block for Cortex-A7 MPCore processor - LEFTBUS/RIGHTBUS block - TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR In original driver present in our internal tree I have separated several CMUs to account for certain factors caused by hardware design, which require such separation. Is there any reason why they were merged together into a single CMU again? This patch just include clocks in CMU clocks without CMU_DMC/CMU_ISP. I'll send a further patches to support CMU_DMC/CMU_ISP after verifying it. Cc: Mike Turquette mturque...@linaro.org Cc: Kukjin Kim kgene@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Signed-off-by: Hyunhee Kim hyunhee@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Seung-Woo Kim sw0312@samsung.com Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Signed-off-by: Karol Wrona k.wr...@samsung.com Signed-off-by: YoungJun Cho yj44@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos3250.c | 785 + include/dt-bindings/clock/exynos3250.h | 256 +++ 3 files changed, 1042 insertions(+) create mode 100644 drivers/clk/samsung/clk-exynos3250.c create mode 100644 include/dt-bindings/clock/exynos3250.h diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile index 8eb4799..d120797 100644 --- a/drivers/clk/samsung/Makefile +++ b/drivers/clk/samsung/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_COMMON_CLK)+= clk.o clk-pll.o +obj-$(CONFIG_SOC_EXYNOS3250)+= clk-exynos3250.o obj-$(CONFIG_ARCH_EXYNOS4)+= clk-exynos4.o obj-$(CONFIG_SOC_EXYNOS5250)+= clk-exynos5250.o obj-$(CONFIG_SOC_EXYNOS5420)+= clk-exynos5420.o diff --git a/drivers/clk/samsung/clk-exynos3250.c b/drivers/clk/samsung/clk-exynos3250.c new file mode 100644 index 000..0574a76 --- /dev/null +++ b/drivers/clk/samsung/clk-exynos3250.c @@ -0,0 +1,785 @@ +/* + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Common Clock Framework support for Exynos3250 SoC. + */ + +#include linux/clk.h +#include linux/clkdev.h +#include linux/clk-provider.h +#include linux/of.h +#include linux/of_address.h +#include linux/platform_device.h +#include linux/syscore_ops.h + +#include dt-bindings/clock/exynos3250.h + +#include clk.h +#include clk-pll.h + +#define SRC_LEFTBUS0x4200 +#define DIV_LEFTBUS0x4500 +#define GATE_IP_LEFTBUS0x4800 +#define SRC_RIGHTBUS0x8200 +#define DIV_RIGHTBUS0x8500 +#define GATE_IP_RIGHTBUS0x8800 +#define GATE_IP_PERIR0x8960 +#define MPLL_LOCK0xc010 +#define MPLL_CON00xc110 +#define VPLL_LOCK0xc020 +#define VPLL_CON00xc120 +#define UPLL_LOCK0xc030 +#define UPLL_CON00xc130 +#define SRC_TOP00xc210 +#define SRC_TOP10xc214 +#define SRC_CAM0xc220 +#define SRC_MFC0xc228 +#define SRC_G3D0xc22c +#define SRC_LCD0xc234 +#define SRC_ISP0xc238 +#define SRC_FSYS0xc240 +#define SRC_PERIL00xc250 +#define SRC_PERIL10xc254 +#define SRC_MASK_TOP0xc310 +#define SRC_MASK_CAM0xc320 +#define SRC_MASK_LCD0xc334 +#define SRC_MASK_ISP0xc338 +#define SRC_MASK_FSYS0xc340 +#define SRC_MASK_PERIL00xc350 +#define SRC_MASK_PERIL10xc354 +#define DIV_TOP0xc510 +#define DIV_CAM0xc520 +#define DIV_MFC0xc528 +#define DIV_G3D0xc52c +#define DIV_LCD0xc534 +#define DIV_ISP0xc538 +#define DIV_FSYS00xc540 +#define DIV_FSYS10xc544 +#define DIV_FSYS20xc548 +#define DIV_PERIL00xc550 +#define DIV_PERIL10xc554 +#define DIV_PERIL30xc55c +#define DIV_PERIL40xc560 +#define
[PATCH v6 0/5] MCPM backend for Exynos5420
This is v6 of the series adding MCPM backend support for SMP secondary boot and core switching on Samsung's Exynos5420. The patches are based on the mcpm support added for Exynos5420 in the Chromium kernel repository here: https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/chromeos-3.8 The patches have been prepared on Kukjin Kim's for-next branch and tested on SMDK5420 EVT1 as well as an exynos5420 based chromebook (peach-pit) using the /dev/b.L_switcher user interface. Secondary core boot-up has also been tested on both the boards. Changes since v5: Addressed the following comments from Kukjin Kim: - The recently merged sysram dt patch has a slightly modified compatible string (exynos4210-sysram-ns). Made the appropriate change in the mcpm back-end to handle this. - Changed the naming of generic cpu/cluster control functions. Correspondingly changed the usage in the mcpm back-end. - Modified hotplug.c to use the generic cpu power down function. - Cleaned up unused S5P_ARM_CORE1_CONFIGURATION and S5P_ARM_CORE1_STATUS macros. - Added a macro for cpu boot address offset and changed debug statement from pr_warn to pr_debug. - Added missing signed-off-by's to the generic cpu/cluster control patches. Changes since v4: Addressed the following comments from Nicolas Pitre: - Fixed the location of L2 prefetching disable code. - Fixed the location of the TODO comment. - Fixed a possible race in mcpm cluster state check in exynos_power_up(). Changes since v3: - Rebased on top of the latest SYSRAM DT patchset from Sachin Kamat. Addressed the following comments from Lorenzo Pieralisi and Nicolas Pitre: - Dropped the patch arm: exynos: Add /dev/bL_status user interface on Exynos5420. - Fixed the header ordering and removed unnecessary header inclusions. - Made the code symmetric in exynos_cluster_power_control(). - Fixed the error path in exynos_power_up. - Got rid of cnt variable used for last man checking. - Removed stale comments. - Replaced soc_is with of_find_compatible_node check for exynos5420. - Added L2 prefetching disable code needed during A15 power down. Changes since v2: Addressed the following comments from Nicolas Pitre and Daniel Lezcano: - Added generic common (cluster) configuration functions to pm.c which may be used by other subsystems. - Removed unused cpumask variable in mcpm code. - Re-worked exynos_power_down_finish() referencing the tc2_pm code. - Removed the status checks in core and cluster power functions. We just set the power control bit and do not check the previous state anymore. - Removed incorrect jiffies timeout usage in path where IRQs are disabled. Changes since v1: Addressed the following comments from Dave Martin and Nicolas Pitre: - Fixed help text for EXYNOS5420_MCPM symbol. - Removed mcpm-exynos-setup.S file and added similar code from tc2_pm.c. - Changed the spinlock name from bl_lock to exynos_mcpm_lock. - Removed snoop enable/disable calls due to possible cpuidle issue and not having numbers proving a significant power savings. Dropped the drivers/bus: arm-cci: Add common control interface for ACE ports patch from v1 as it was no longer needed. - Created a macro for exynos-specific v7_exit_coherency_flush which handles an erratum. This was done to prevent duplication of code. - Removed outer_flush_all call. - Removed redundant dsb in power_down function. - Removed unnecessary initialization of global variables to zero. - Split the /dev/bL_status debug interface into another patch. - Fixed error handling in exynos_mcpm_init(). - Called mcpm_smp_set_ops directly from exynos_mcpm_init(). - Added a TODO for supporting cluster down on exynos5420. NOTE: - Have added Leela Krishna's generic cpu power control function series as part of this patchset. - I have tested with and without the erratum 799270 workaround and both work fine. I have kept the erratum fix for the time being. Abhilash Kesavan (2): arm: exynos: Add generic cluster power control functions arm: exynos: Add MCPM call-back functions Andrew Bresticker (1): ARM: dts: exynos5420: add CCI node Leela Krishna Amudala (2): ARM: EXYNOS: Add generic cpu power control functions for all exynos based SoCs ARM: EXYNOS: use generic exynos cpu power control functions arch/arm/boot/dts/exynos5420.dtsi | 27 +++ arch/arm/mach-exynos/Kconfig |8 + arch/arm/mach-exynos/Makefile |2 + arch/arm/mach-exynos/common.h |6 + arch/arm/mach-exynos/hotplug.c |2 +- arch/arm/mach-exynos/mcpm-exynos.c | 346
[PATCH v6 2/5] ARM: EXYNOS: use generic exynos cpu power control functions
From: Leela Krishna Amudala leela.kris...@linaro.org
Use generic exynos cpu power control functions to power up/down
and to know the status of the cpu in platsmp and hotplug code.
Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
arch/arm/mach-exynos/hotplug.c |2 +-
arch/arm/mach-exynos/platsmp.c |9 +++--
arch/arm/mach-exynos/regs-pmu.h |3 ---
3 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 3cab3f5..69fa483 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -44,7 +44,7 @@ static inline void platform_do_lowpower(unsigned int cpu, int
*spurious)
/* make cpu1 to be turned off at next WFI command */
if (cpu == 1)
- __raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
+ exynos_cpu_power_down(cpu);
/*
* here's the WFI
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 51cdabe..9c16da2 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -131,15 +131,12 @@ static int exynos_boot_secondary(unsigned int cpu, struct
task_struct *idle)
*/
write_pen_release(phys_cpu);
- if (!(__raw_readl(S5P_ARM_CORE1_STATUS) S5P_CORE_LOCAL_PWR_EN)) {
- __raw_writel(S5P_CORE_LOCAL_PWR_EN,
-S5P_ARM_CORE1_CONFIGURATION);
-
+ if (!exynos_cpu_power_state(cpu)) {
+ exynos_cpu_power_up(cpu);
timeout = 10;
/* wait max 10 ms until cpu1 is on */
- while ((__raw_readl(S5P_ARM_CORE1_STATUS)
-S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN) {
+ while (exynos_cpu_power_state(cpu) != S5P_CORE_LOCAL_PWR_EN) {
if (timeout-- == 0)
break;
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 84634ac..98fb8d8 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -111,9 +111,6 @@
#define EXYNOS_ARM_CORE_STATUS(_nr)\
(EXYNOS_ARM_CORE_CONFIGURATION(_nr) + 0x4)
-#define S5P_ARM_CORE1_CONFIGURATIONS5P_PMUREG(0x2080)
-#define S5P_ARM_CORE1_STATUS S5P_PMUREG(0x2084)
-
#define S5P_PAD_RET_MAUDIO_OPTION S5P_PMUREG(0x3028)
#define S5P_PAD_RET_GPIO_OPTIONS5P_PMUREG(0x3108)
#define S5P_PAD_RET_UART_OPTIONS5P_PMUREG(0x3128)
--
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 v6 1/5] ARM: EXYNOS: Add generic cpu power control functions for all exynos based SoCs
From: Leela Krishna Amudala leela.kris...@linaro.org
Add generic cpu power control functions for exynos based SoCS
for cpu power up/down and to know the cpu status.
Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
arch/arm/mach-exynos/common.h |3 +++
arch/arm/mach-exynos/pm.c | 36
arch/arm/mach-exynos/regs-pmu.h |6 ++
3 files changed, 45 insertions(+)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 278b573..20adc2c 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -132,6 +132,9 @@ struct exynos_pmu_conf {
};
extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+extern void exynos_cpu_power_down(int cpu);
+extern void exynos_cpu_power_up(int cpu);
+extern int exynos_cpu_power_state(int cpu);
extern void s5p_init_cpu(void __iomem *cpuid_addr);
extern unsigned int samsung_rev(void);
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index ca672e2..60c3356 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -99,6 +99,42 @@ static int exynos_irq_set_wake(struct irq_data *data,
unsigned int state)
return -ENOENT;
}
+/**
+ * exynos_core_power_down : power down the specified cpu
+ * @cpu : the cpu to power down
+ *
+ * Power down the specified cpu. The sequence must be finished by a
+ * call to cpu_do_idle()
+ *
+ */
+void exynos_cpu_power_down(int cpu)
+{
+ __raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+}
+
+/**
+ * exynos_cpu_power_up : power up the specified cpu
+ * @cpu : the cpu to power up
+ *
+ * Power up the specified cpu
+ */
+void exynos_cpu_power_up(int cpu)
+{
+ __raw_writel(S5P_CORE_LOCAL_PWR_EN,
+EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+}
+
+/**
+ * exynos_cpu_power_state : returns the power state of the cpu
+ * @cpu : the cpu to retrieve the power state from
+ *
+ */
+int exynos_cpu_power_state(int cpu)
+{
+ return (__raw_readl(EXYNOS_ARM_CORE_STATUS(cpu))
+ S5P_CORE_LOCAL_PWR_EN);
+}
+
/* For Cortex-A9 Diagnostic and Power control register */
static unsigned int save_arm_register[2];
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 4f6a256..84634ac 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -105,6 +105,12 @@
#define S5P_GPS_LOWPWR S5P_PMUREG(0x139C)
#define S5P_GPS_ALIVE_LOWPWR S5P_PMUREG(0x13A0)
+#define EXYNOS_ARM_CORE0_CONFIGURATION S5P_PMUREG(0x2000)
+#define EXYNOS_ARM_CORE_CONFIGURATION(_nr) \
+ (EXYNOS_ARM_CORE0_CONFIGURATION + (0x80 * (_nr)))
+#define EXYNOS_ARM_CORE_STATUS(_nr)\
+ (EXYNOS_ARM_CORE_CONFIGURATION(_nr) + 0x4)
+
#define S5P_ARM_CORE1_CONFIGURATIONS5P_PMUREG(0x2080)
#define S5P_ARM_CORE1_STATUS S5P_PMUREG(0x2084)
--
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 v6 3/5] arm: exynos: Add generic cluster power control functions
Add generic cluster power control functions for exynos based SoCS
for cluster power up/down and to know the cluster status.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
arch/arm/mach-exynos/common.h |3 +++
arch/arm/mach-exynos/pm.c | 30 ++
arch/arm/mach-exynos/regs-pmu.h |6 ++
3 files changed, 39 insertions(+)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 20adc2c..ae5f648 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -135,6 +135,9 @@ extern void exynos_sys_powerdown_conf(enum sys_powerdown
mode);
extern void exynos_cpu_power_down(int cpu);
extern void exynos_cpu_power_up(int cpu);
extern int exynos_cpu_power_state(int cpu);
+extern void exynos_cluster_power_down(int cluster);
+extern void exynos_cluster_power_up(int cluster);
+extern int exynos_cluster_power_state(int cluster);
extern void s5p_init_cpu(void __iomem *cpuid_addr);
extern unsigned int samsung_rev(void);
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 60c3356..aba2ff6 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -135,6 +135,36 @@ int exynos_cpu_power_state(int cpu)
S5P_CORE_LOCAL_PWR_EN);
}
+/**
+ * exynos_cluster_power_down : power down the specified cluster
+ * @cluster : the cluster to power down
+ */
+void exynos_cluster_power_down(int cluster)
+{
+ __raw_writel(0, EXYNOS_COMMON_CONFIGURATION(cluster));
+}
+
+/**
+ * exynos_cluster_power_up : power up the specified cluster
+ * @cluster : the cluster to power up
+ */
+void exynos_cluster_power_up(int cluster)
+{
+ __raw_writel(S5P_CORE_LOCAL_PWR_EN,
+EXYNOS_COMMON_CONFIGURATION(cluster));
+}
+
+/**
+ * exynos_cluster_power_state : returns the power state of the cluster
+ * @cluster : the cluster to retrieve the power state from
+ *
+ */
+int exynos_cluster_power_state(int cluster)
+{
+ return (__raw_readl(EXYNOS_COMMON_STATUS(cluster))
+ S5P_CORE_LOCAL_PWR_EN);
+}
+
/* For Cortex-A9 Diagnostic and Power control register */
static unsigned int save_arm_register[2];
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 98fb8d8..f6b68a3 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -111,6 +111,12 @@
#define EXYNOS_ARM_CORE_STATUS(_nr)\
(EXYNOS_ARM_CORE_CONFIGURATION(_nr) + 0x4)
+#define EXYNOS_ARM_COMMON_CONFIGURATIONS5P_PMUREG(0x2500)
+#define EXYNOS_COMMON_CONFIGURATION(_nr) \
+ (EXYNOS_ARM_COMMON_CONFIGURATION + (0x80 * (_nr)))
+#define EXYNOS_COMMON_STATUS(_nr) \
+ (EXYNOS_COMMON_CONFIGURATION(_nr) + 0x4)
+
#define S5P_PAD_RET_MAUDIO_OPTION S5P_PMUREG(0x3028)
#define S5P_PAD_RET_GPIO_OPTIONS5P_PMUREG(0x3108)
#define S5P_PAD_RET_UART_OPTIONS5P_PMUREG(0x3128)
--
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 v6 4/5] ARM: dts: exynos5420: add CCI node
From: Andrew Bresticker abres...@chromium.org
Add device-tree bindings for the ARM CCI-400 on Exynos5420. There
are two slave interfaces: one for the A15 cluster and one for the
A7 cluster.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 0cd65a7..e170c3c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -58,6 +58,7 @@
compatible = arm,cortex-a15;
reg = 0x0;
clock-frequency = 18;
+ cci-control-port = cci_control1;
};
cpu1: cpu@1 {
@@ -65,6 +66,7 @@
compatible = arm,cortex-a15;
reg = 0x1;
clock-frequency = 18;
+ cci-control-port = cci_control1;
};
cpu2: cpu@2 {
@@ -72,6 +74,7 @@
compatible = arm,cortex-a15;
reg = 0x2;
clock-frequency = 18;
+ cci-control-port = cci_control1;
};
cpu3: cpu@3 {
@@ -79,6 +82,7 @@
compatible = arm,cortex-a15;
reg = 0x3;
clock-frequency = 18;
+ cci-control-port = cci_control1;
};
cpu4: cpu@100 {
@@ -86,6 +90,7 @@
compatible = arm,cortex-a7;
reg = 0x100;
clock-frequency = 10;
+ cci-control-port = cci_control0;
};
cpu5: cpu@101 {
@@ -93,6 +98,7 @@
compatible = arm,cortex-a7;
reg = 0x101;
clock-frequency = 10;
+ cci-control-port = cci_control0;
};
cpu6: cpu@102 {
@@ -100,6 +106,7 @@
compatible = arm,cortex-a7;
reg = 0x102;
clock-frequency = 10;
+ cci-control-port = cci_control0;
};
cpu7: cpu@103 {
@@ -107,6 +114,26 @@
compatible = arm,cortex-a7;
reg = 0x103;
clock-frequency = 10;
+ cci-control-port = cci_control0;
+ };
+ };
+
+ cci@10d2 {
+ compatible = arm,cci-400;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x10d2 0x1000;
+ ranges = 0x0 0x10d2 0x6000;
+
+ cci_control0: slave-if@4000 {
+ compatible = arm,cci-400-ctrl-if;
+ interface-type = ace;
+ reg = 0x4000 0x1000;
+ };
+ cci_control1: slave-if@5000 {
+ compatible = arm,cci-400-ctrl-if;
+ interface-type = ace;
+ reg = 0x5000 0x1000;
};
};
--
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 v4 0/4] Adds PMU and S2R support for exynos5420
Rebased on 1] Kukjin Kim's tree for-next branch (which has Sachin Kamat's SYSRAM patches merged) with Tomasz Figa's samsung clock tree (samsung-next branch) merged. https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next 2] Pankaj Dubey's v4 PMU patchset https://lkml.org/lkml/2014/5/10/29 Pankaj's patches have the following dependencies: [1] mfd: syscon: Support early initialization https://lkml.org/lkml/2014/4/8/239 [2] Daniel Lezcano's Exynos cpuidle refactor patches http://thread.gmane.org/gmane.linux.kernel.samsung-soc/29085 [3] Allow NULL property in syscon_early_regmap_lookup_by_phandle https://lkml.org/lkml/2014/5/10/10 and https://lkml.org/lkml/2014/4/29/661 Note: Some of the above patches did not apply cleanly on Kgene's for-next branch. changes since v3: Addressed the following comments from Pankaj Dubey, Bartlomiej Zolnierkiewicz, Tomasz Figa and Alim Akhtar: - Moved EXYNOS5420_USE_STANDBY_WFI_ALL define to regs-pmu.h. - Merged exynos5420_set_core_flag function into powerdown_conf. - Removed XXTI_DURATION3 register setting. - Updated the commit message and ordered the clock registers in clock patch. - Removed the code for SYS_DISP1_BLK_CFG handling. - Modified SoC checks to A9 specific checks in PM code. - Updated some comments in the code and added macros for register offsets. - Fixed code which was changing pad retention code for older SoCs. changes since v2: - Addressed comments from Tomasz figa - rebased on Pankaj's V3 patchset https://lkml.org/lkml/2014/5/2/612 - dropped patch ARM: dts: Add node for GPIO keys on SMDK5420, will be sent separately. changes since v1: - Addressed comments from Tomasz figa. - restructured/consolidated as per Tomasz figa's PM consolidations for exynos Tested on Exynos5420 and Exynos5250 based chromebooks (peach-pit and snow). Abhilash Kesavan (4): arm: exynos5: Add PMU support for 5420 arm: exynos: Modify code to check for cortex A9 rather than the SoC arm: exynos5: Add Suspend-to-RAM support for 5420 clk: samsung: exynos5420: Setup clocks before system suspend arch/arm/mach-exynos/exynos.c|1 + arch/arm/mach-exynos/pm.c| 216 --- arch/arm/mach-exynos/pmu.c | 310 ++ arch/arm/mach-exynos/regs-pmu.h | 239 ++ drivers/clk/samsung/clk-exynos5420.c | 25 +++ 5 files changed, 769 insertions(+), 22 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 v4 1/4] arm: exynos5: Add PMU support for 5420
Add intial PMU settings for exynos5420. This is required for
future S2R and Switching support.
Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/exynos.c |1 +
arch/arm/mach-exynos/pmu.c | 310 +++
arch/arm/mach-exynos/regs-pmu.h | 238 ++
3 files changed, 549 insertions(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index a391e38..c7eda4c 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -207,6 +207,7 @@ static const struct of_device_id exynos_dt_pmu_match[] = {
{ .compatible = samsung,exynos4212-pmu },
{ .compatible = samsung,exynos4412-pmu },
{ .compatible = samsung,exynos5250-pmu },
+ { .compatible = samsung,exynos5420-pmu },
{},
};
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index bc3cd3f..c4c363e 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -9,6 +9,7 @@
* published by the Free Software Foundation.
*/
+#include linux/delay.h
#include linux/module.h
#include linux/regmap.h
@@ -17,6 +18,8 @@
#include linux/slab.h
#include linux/mfd/syscon.h
+#include asm/cputype.h
+
#include exynos-pmu.h
#include regs-pmu.h
@@ -333,6 +336,151 @@ static const struct exynos_pmu_conf
exynos5250_pmu_config[] = {
{ PMU_TABLE_END,},
};
+static struct exynos_pmu_conf exynos5420_pmu_config[] = {
+ /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
+ { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
+ { EXYNOS5_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
+ { EXYNOS5420_ARM_CORE2_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_ARM_CORE3_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE3_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_KFC_CORE0_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_KFC_CORE1_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_KFC_CORE2_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE2_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_KFC_CORE3_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE3_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5_ISP_ARM_SYS_PWR_REG, { 0x1, 0x0,
0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x1, 0x0,
0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG, { 0x1, 0x0,
0x0} },
+ { EXYNOS5420_ARM_COMMON_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
+ { EXYNOS5420_KFC_COMMON_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
+ { EXYNOS5_ARM_L2_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_KFC_L2_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
+ { EXYNOS5_CMU_ACLKSTOP_SYS_PWR_REG, { 0x1, 0x0,
0x0} },
+ { EXYNOS5_CMU_SCLKSTOP_SYS_PWR_REG, { 0x1, 0x0,
0x1} },
+ { EXYNOS5_CMU_RESET_SYS_PWR_REG,{ 0x1, 0x1,
0x0} },
+ { EXYNOS5_CMU_ACLKSTOP_SYSMEM_SYS_PWR_REG, { 0x1, 0x0,
0x0} },
+ { EXYNOS5_CMU_SCLKSTOP_SYSMEM_SYS_PWR_REG, { 0x1, 0x0,
0x1} },
+ { EXYNOS5_CMU_RESET_SYSMEM_SYS_PWR_REG, { 0x1, 0x1,
0x0} },
+ { EXYNOS5_DRAM_FREQ_DOWN_SYS_PWR_REG, { 0x1, 0x0,
0x1} },
+ { EXYNOS5_DDRPHY_DLLOFF_SYS_PWR_REG,{ 0x1, 0x1,
0x1} },
+ {
[PATCH v4 2/4] arm: exynos: Modify code to check for cortex A9 rather than the SoC
We have an soc check to ensure that the scu and certain A9 specific
registers are not accessed on Exynos5250 (which is A15 based).
Rather than adding another soc specific check for 5420 let us test
for the Cortex A9 primary part number.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
arch/arm/mach-exynos/pm.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 5effd38..95f8086 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -248,7 +248,7 @@ static int exynos_pm_suspend(void)
tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
regmap_write(pmu_regmap, S5P_CENTRAL_SEQ_OPTION, tmp);
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
exynos_cpu_save_register();
return 0;
@@ -282,7 +282,7 @@ static void exynos_pm_resume(void)
if (exynos_pm_central_resume())
goto early_wakeup;
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
exynos_cpu_restore_register();
/* For release retention */
@@ -301,7 +301,7 @@ static void exynos_pm_resume(void)
s3c_pm_do_restore_core(exynos_core_save, ARRAY_SIZE(exynos_core_save));
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
scu_enable(S5P_VA_SCU);
early_wakeup:
@@ -388,15 +388,18 @@ static int exynos_cpu_pm_notifier(struct notifier_block
*self,
case CPU_PM_ENTER:
if (cpu == 0) {
exynos_pm_central_suspend();
- exynos_cpu_save_register();
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
+ exynos_cpu_save_register();
}
break;
case CPU_PM_EXIT:
if (cpu == 0) {
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() ==
+ ARM_CPU_PART_CORTEX_A9) {
scu_enable(S5P_VA_SCU);
- exynos_cpu_restore_register();
+ exynos_cpu_restore_register();
+ }
exynos_pm_central_resume();
}
break;
--
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 v6 5/5] arm: exynos: Add MCPM call-back functions
Add machine-dependent MCPM call-backs for Exynos5420. These are used
to power up/down the secondary CPUs during boot, shutdown, s2r and
switching.
Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Inderpal Singh inderpa...@samsung.com
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Nicolas Pitre nicolas.pi...@linaro.org
---
arch/arm/mach-exynos/Kconfig |8 +
arch/arm/mach-exynos/Makefile |2 +
arch/arm/mach-exynos/mcpm-exynos.c | 346
arch/arm/mach-exynos/regs-pmu.h|3 +
4 files changed, 359 insertions(+)
create mode 100644 arch/arm/mach-exynos/mcpm-exynos.c
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..1602abc 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -110,4 +110,12 @@ config SOC_EXYNOS5440
endmenu
+config EXYNOS5420_MCPM
+ bool Exynos5420 Multi-Cluster PM support
+ depends on MCPM SOC_EXYNOS5420
+ select ARM_CCI
+ help
+ This is needed to provide CPU and cluster power management
+ on Exynos5420 implementing big.LITTLE.
+
endif
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index f6dcc25..2e0666d 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -24,3 +24,5 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_exynos-smc.o:=-Wa,-march=armv7-a$(plus_sec)
+
+obj-$(CONFIG_EXYNOS5420_MCPM) += mcpm-exynos.o
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
new file mode 100644
index 000..ec4ae00
--- /dev/null
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -0,0 +1,346 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * arch/arm/mach-exynos/mcpm-exynos.c
+ *
+ * Based on arch/arm/mach-vexpress/dcscb.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/arm-cci.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/of_address.h
+
+#include asm/cputype.h
+#include asm/cp15.h
+#include asm/mcpm.h
+
+#include regs-pmu.h
+#include common.h
+
+#define EXYNOS5420_CPUS_PER_CLUSTER4
+#define EXYNOS5420_NR_CLUSTERS 2
+#define MCPM_BOOT_ADDR_OFFSET 0x1c
+
+/* Non-secure iRAM base address */
+static void __iomem *ns_sram_base_addr;
+
+/*
+ * The common v7_exit_coherency_flush API could not be used because of the
+ * Erratum 799270 workaround. This macro is the same as the common one (in
+ * arch/arm/include/asm/cacheflush.h) except for the erratum handling.
+ */
+#define exynos_v7_exit_coherency_flush(level) \
+ asm volatile( \
+ stmfd sp!, {fp, ip}\n\t\
+ mrcp15, 0, r0, c1, c0, 0 @ get SCTLR\n\t \
+ bicr0, r0, #__stringify(CR_C)\n\t \
+ mcrp15, 0, r0, c1, c0, 0 @ set SCTLR\n\t \
+ isb\n\t\
+ bl v7_flush_dcache___stringify(level)\n\t \
+ clrex\n\t\
+ mrcp15, 0, r0, c1, c0, 1 @ get ACTLR\n\t \
+ bicr0, r0, #(1 6) @ disable local coherency\n\t \
+ /* Dummy Load of a device register to avoid Erratum 799270 */ \
+ ldrr4, [%0]\n\t \
+ andr4, r4, #0\n\t \
+ orrr0, r0, r4\n\t \
+ mcrp15, 0, r0, c1, c0, 1 @ set ACTLR\n\t \
+ isb\n\t \
+ dsb\n\t \
+ ldmfd sp!, {fp, ip} \
+ : \
+ : Ir (S5P_INFORM0) \
+ : r0, r1, r2, r3, r4, r5, r6, r7, \
+ r9, r10, lr, memory)
+
+/*
+ * We can't use regular spinlocks. In the switcher case, it is possible
+ * for an outbound CPU to call power_down() after its inbound counterpart
+ * is already live using the same logical CPU number which trips lockdep
+ * debugging.
+ */
+static arch_spinlock_t exynos_mcpm_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int
+cpu_use_count[EXYNOS5420_CPUS_PER_CLUSTER][EXYNOS5420_NR_CLUSTERS];
+
+#define exynos_cluster_usecnt(cluster) \
+ (cpu_use_count[0][cluster] + \
+cpu_use_count[1][cluster] + \
+cpu_use_count[2][cluster] + \
+cpu_use_count[3][cluster])
+
+#define exynos_cluster_unused(cluster) !exynos_cluster_usecnt(cluster)
+
+static int exynos_cluster_power_control(unsigned int cluster, int enable)
+{
+ unsigned int tries = 100;
+ unsigned int val;
+
+ if (enable) {
+ exynos_cluster_power_up(cluster);
+ val = S5P_CORE_LOCAL_PWR_EN;
+ } else {
+ exynos_cluster_power_down(cluster);
+ val = 0;
+ }
+
+ /* Wait until cluster power control is applied */
+ while (tries--) {
+ if (exynos_cluster_power_state(cluster) == val)
+ return
[PATCH v4 4/4] clk: samsung: exynos5420: Setup clocks before system suspend
Prior to suspending the system, we need to ensure that certain
clock source and gate registers are unmasked.
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index e576456..dd509d1 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -28,6 +28,7 @@
#define GATE_BUS_CPU 0x700
#define GATE_SCLK_CPU 0x800
#define CLKOUT_CMU_CPU 0xa00
+#define SRC_MASK_CPERI 0x4300
#define GATE_IP_G2D0x8800
#define CPLL_LOCK 0x10020
#define DPLL_LOCK 0x10030
@@ -66,6 +67,8 @@
#define SRC_TOP10 0x10280
#define SRC_TOP11 0x10284
#define SRC_TOP12 0x10288
+#define SRC_MASK_TOP0 0x10300
+#define SRC_MASK_TOP1 0x10304
#define SRC_MASK_TOP2 0x10308
#define SRC_MASK_TOP7 0x1031c
#define SRC_MASK_DISP100x1032c
@@ -73,6 +76,7 @@
#define SRC_MASK_FSYS 0x10340
#define SRC_MASK_PERIC00x10350
#define SRC_MASK_PERIC10x10354
+#define SRC_MASK_ISP 0x10370
#define DIV_TOP0 0x10500
#define DIV_TOP1 0x10504
#define DIV_TOP2 0x10508
@@ -91,6 +95,7 @@
#define DIV2_RATIO00x10590
#define DIV4_RATIO 0x105a0
#define GATE_BUS_TOP 0x10700
+#define GATE_BUS_DISP1 0x10728
#define GATE_BUS_GEN 0x1073c
#define GATE_BUS_FSYS0 0x10740
#define GATE_BUS_FSYS2 0x10748
@@ -115,6 +120,7 @@
#define GATE_TOP_SCLK_MAU 0x1083c
#define GATE_TOP_SCLK_FSYS 0x10840
#define GATE_TOP_SCLK_PERIC0x10850
+#define GATE_IP_PERIC 0x10950
#define TOP_SPARE2 0x10b08
#define BPLL_LOCK 0x20010
#define BPLL_CON0 0x20110
@@ -222,11 +228,30 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
DIV_KFC0,
};
+static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
+ { .offset = SRC_MASK_CPERI, .value = 0x, },
+ { .offset = SRC_MASK_TOP0, .value = 0x, },
+ { .offset = SRC_MASK_TOP1, .value = 0x1110, },
+ { .offset = SRC_MASK_TOP2, .value = 0x1110, },
+ { .offset = SRC_MASK_TOP7, .value = 0x0000, },
+ { .offset = SRC_MASK_DISP10,.value = 0x1110, },
+ { .offset = SRC_MASK_MAU, .value = 0x1000, },
+ { .offset = SRC_MASK_FSYS, .value = 0x1110, },
+ { .offset = SRC_MASK_PERIC0,.value = 0x1110, },
+ { .offset = SRC_MASK_PERIC1,.value = 0x1100, },
+ { .offset = SRC_MASK_ISP, .value = 0x1000, },
+ { .offset = GATE_BUS_DISP1, .value = 0x, },
+ { .offset = GATE_IP_PERIC, .value = 0x, },
+};
+
static int exynos5420_clk_suspend(void)
{
samsung_clk_save(reg_base, exynos5420_save,
ARRAY_SIZE(exynos5420_clk_regs));
+ samsung_clk_restore(reg_base, exynos5420_set_clksrc,
+ ARRAY_SIZE(exynos5420_set_clksrc));
+
return 0;
}
--
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 v4 3/4] arm: exynos5: Add Suspend-to-RAM support for 5420
Adds Suspend-to-RAM support for EXYNOS5420
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/pm.c | 201 +++
arch/arm/mach-exynos/regs-pmu.h |1 +
2 files changed, 186 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 95f8086..fddb559 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -22,6 +22,7 @@
#include linux/err.h
#include linux/clk.h
#include linux/regmap.h
+#include linux/of_address.h
#include asm/cacheflush.h
#include asm/hardware/cache-l2x0.h
@@ -39,7 +40,13 @@
#include regs-sys.h
#include exynos-pmu.h
+#define EXYNOS5420_CPU_ADDR0x1c
+#define EXYNOS5420_CPU_STATE 0x28
+
static struct regmap *pmu_regmap;
+static int exynos5420_cpu_state[2];
+static void __iomem *exynos5420_sysram_base;
+static void __iomem *exynos5420_ns_sysram_base;
/**
* struct exynos_wkup_irq - Exynos GIC to PMU IRQ mapping
@@ -64,6 +71,10 @@ static struct sleep_save exynos_core_save[] = {
SAVE_ITEM(S5P_SROM_BC3),
};
+static struct sleep_save exynos5420_pmu_reg_save[] = {
+ SAVE_ITEM((void __iomem *)S5P_PMU_SPARE3),
+};
+
/*
* GIC wake-up support
*/
@@ -86,7 +97,7 @@ static int exynos_irq_set_wake(struct irq_data *data,
unsigned int state)
{
const struct exynos_wkup_irq *wkup_irq;
- if (soc_is_exynos5250())
+ if (soc_is_exynos5250() || soc_is_exynos5420())
wkup_irq = exynos5250_wkup_irq;
else
wkup_irq = exynos4_wkup_irq;
@@ -187,7 +198,16 @@ static int exynos_cpu_suspend(unsigned long arg)
outer_flush_all();
#endif
- if (soc_is_exynos5250())
+ /*
+* Clear sysram register for cpu state so that primary CPU does
+* not enter low power start in U-Boot.
+* This is specific to exynos5420 SoC only.
+*/
+ if (soc_is_exynos5420())
+ __raw_writel(0x0,
+ exynos5420_sysram_base + EXYNOS5420_CPU_STATE);
+
+ if (soc_is_exynos5250() || soc_is_exynos5420())
flush_cache_all();
/* issue the standby signal into the pm unit. */
@@ -215,6 +235,24 @@ static void exynos_pm_prepare(void)
regmap_read(pmu_regmap, EXYNOS5_JPEG_MEM_OPTION, tmp);
tmp = ~EXYNOS5_OPTION_USE_RETENTION;
regmap_write(pmu_regmap, EXYNOS5_JPEG_MEM_OPTION, tmp);
+ } else if (soc_is_exynos5420()) {
+ unsigned int i;
+
+ for (i = 0; i ARRAY_SIZE(exynos5420_pmu_reg_save); i++)
+ regmap_read(pmu_regmap,
+ (unsigned int)exynos5420_pmu_reg_save[i].reg,
+ (unsigned int *)exynos5420_pmu_reg_save[i].val);
+ /*
+* The cpu state needs to be saved and restored so that the
+* secondary CPUs will enter low power start. Though the U-Boot
+* is setting the cpu state with low power flag, the kernel
+* needs to restore it back in case, the primary cpu fails to
+* suspend for any reason.
+*/
+ exynos5420_cpu_state[0] =
+ __raw_readl(exynos5420_sysram_base + EXYNOS5420_CPU_STATE);
+ exynos5420_cpu_state[1] =
+ __raw_readl(exynos5420_ns_sysram_base + EXYNOS5420_CPU_ADDR);
}
/* Set value of power down register for sleep mode */
@@ -225,6 +263,26 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
regmap_write(pmu_regmap, S5P_INFORM0, virt_to_phys(exynos_cpu_resume));
+
+ if (soc_is_exynos5420()) {
+ regmap_read(pmu_regmap, EXYNOS5_ARM_L2_OPTION, tmp);
+ tmp = ~EXYNOS5_USE_RETENTION;
+ regmap_write(pmu_regmap, EXYNOS5_ARM_L2_OPTION, tmp);
+
+ regmap_read(pmu_regmap, EXYNOS5420_SFR_AXI_CGDIS1, tmp);
+ tmp |= EXYNOS5420_UFS;
+ regmap_write(pmu_regmap, EXYNOS5420_SFR_AXI_CGDIS1, tmp);
+
+ regmap_read(pmu_regmap, EXYNOS5420_ARM_COMMON_OPTION, tmp);
+ tmp = ~EXYNOS5420_L2RSTDISABLE_VALUE;
+ regmap_write(pmu_regmap, EXYNOS5420_ARM_COMMON_OPTION, tmp);
+ regmap_read(pmu_regmap, EXYNOS5420_FSYS2_OPTION, tmp);
+ tmp |= EXYNOS5420_EMULATION;
+ regmap_write(pmu_regmap, EXYNOS5420_FSYS2_OPTION, tmp);
+ regmap_read(pmu_regmap, EXYNOS5420_PSGEN_OPTION, tmp);
+ tmp |= EXYNOS5420_EMULATION;
+ regmap_write(pmu_regmap, EXYNOS5420_PSGEN_OPTION, tmp);
+ }
}
static void exynos_pm_central_suspend(void)
@@ -241,12 +299,22 @@ static int exynos_pm_suspend(void)
{
unsigned int tmp;
+ unsigned int this_cluster;
exynos_pm_central_suspend();
/* Setting
Re: [RFC V2 0/3] drm/bridge: panel and chaining
On 05/12/2014 06:00 PM, Sean Paul wrote:
On Mon, May 12, 2014 at 3:06 AM, Andrzej Hajda a.ha...@samsung.com wrote:
On 05/09/2014 05:05 PM, Ajay kumar wrote:
On Fri, May 9, 2014 at 7:29 PM, Rob Clark robdcl...@gmail.com wrote:
On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda a.ha...@samsung.com wrote:
On 05/08/2014 08:24 PM, Rob Clark wrote:
On Thu, May 8, 2014 at 2:41 AM, Andrzej Hajda a.ha...@samsung.com
wrote:
On 05/05/2014 09:52 PM, Ajay Kumar wrote:
This patchset is based on exynos-drm-next-todo branch of Inki Dae's
tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have just put up Rob's and Sean's idea of chaining up the bridges
in code, and have implemented basic panel controls as a chained bridge.
This works well with ptn3460 bridge chip on exynos5250-snow board.
Still need to make use of standard list calls and figure out proper way
of deleting the bridge chain. So, this is just a rough version.
As I understand this patchset tries to solve two things:
1. Implement panel as drm_bridge, to ease support for hardware chains:
Crtc - Encoder - Bridge - Panel
2. Add support to drm_bridge chaining, to allow software chains:
drm_crtc - drm_encoder - drm_bridge - drm_bridge,panel
It is done using Russian doll schema, ops from the bridge calls the same
ops from the next bridge and the next bridge ops can do the same.
This schema means that all the bridges including the last one are seen
from the drm core point of view as a one big drm_bridge. Additionally in
this particular case, the first bridge (ptn3460) implements connector
so it is hard to guess what is the location of the 2nd bridge in video
stream chain, sometimes it is after the connector, sometimes before.
All this is quite confusing.
But if you look at the bridge from upstream video interface point of
view it is just a panel, edp panel in case of ptn3460, ie ptn3460 on its
video input side acts as a panel. On the output side it expects a panel,
lvds panel in this case.
tbh, this is mostly about what we call it. Perhaps bridge isn't the
best name.. I wouldn't object to changing it.
But my thinking was to leave in drm_panel_funcs things that are just
needed by the connector (get_modes().. and maybe some day we need
detect/etc). Then leave everything else in drm_bridge_funcs. A panel
could (if needed) implement both interfaces.
That is basically the same as what you are proposing, but without
renaming bridge to panel ;-)
Good to hear that. However there are points which are not clear for me.
But first lets clarify names, I will use panel and bridge words
to describe the hardware, and drm_panel, drm_bridge to describe the
software interfaces.
What bothers me:
1. You want to leave connector related callbacks in drm_panel and
the rest in drm_bridge. In case of ptn3460 it does not work, ptn3460
must implement connector internally because of this limitation. I guess
it is quite typical bridge. This problem does not exists in case
of using drm_panel for ptn3460.
2. drm_bridge is attached to the encoder, this and the callback order
suggests the video data flow should be as below:
drm_crtc - drm_encoder [- drm_bridge] - drm_connector [- drm_panel]
ptn3460 implements drm_bridge and drm_connector so it suggests its
drm_bridge should be the last one, so there should be no place to add
lvds panel implemented as a drm_bridge after it, as it is done in this
patchset.
Additionally it clearly shows that there should be two categories of
drm_bridges - non-terminal and terminal.
3. drm_dev uses all-or-nothing approach, ie. it will start only when all
its components are up. It simplifies synchronization but is quite
fragile - the whole drm will be down due to error in some of its
components.
For this reason I prefer drm_panel as it is not real drm component
it can be attached/detached to/from drm_connector anytime. I am not
really sure but drm_bridge does not allow for that.
So I do think we need to stick to this all-or-nothing approach for
anything that is visible to userspace
(drm_{plane,crtc,encoder,connector}). We don't currently have a way
to hotplug those so I don't see a real smooth upgrade path to add
that in a backwards compatible way that won't cause problems with old
userspace.
But, that said, we have more flexibility with things not visible to
userspace (drm_{panel,bridge}). I'm not sure how much we want to
allow things to be completely dynamic (we already have some hard
enough locking fun). But proposals/rfcs/etc welcome.
I guess I'm not completely familiar w/ ptn3460, but the fact that it
needs to implement drm_connector makes me a bit suspicious. Seems
like a symptom of missing things in drm_panel_funcs. It would be
better to always create the connector statically, and just have
_detect() - disconnected if panel==NULL.
ptn3460 has been implemented using drm_bridge and drm_connector, not by
me, to be clear :)
Right,
[PATCHv5 0/5] Support new Exynos3250 SoC based on Cortex-A7 dual core
This patchset support new Exynos3250 Samsung SoC based on Cortex-A7 dual core. Exynos3250 is a System-On-Chip (SoC) that is based on 32-bit RISC processor for Smartphone. It is desigend with the 28nm low-power high-K metal gate process and provides the best performance features. This patchset include some patches such as: - Support booting of Exynos3250 - Supoort uart/mct/adc/gic/i2c/spi/power-domain/pmu/mshc/pwm/amba - Support the clock control for Exynos3250 using common clk framework This patchset is based on following git repo/branch. - git repo : git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git - branch : for-next (2ca8b247775d7c24fa8c2524a5562bad7e88f84b) Changes from v4: - Rebase this patch on latest for-next branch in linux-samsung.git - Post separated secondary CPU boot patch for Exynos4212 and merged it : https://lkml.org/lkml/2014/5/8/745 - Drop following patch[1] and use alternative patch[2] to turn off Cortex-A7 [1] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7 [2] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29064.html - Modify clock driver of exynos3250 - Add 'soc' dt node and move all dt nodes under 'soc' dt node in exynos3250.dtsi - Add missing CPU1 dt node in exynos3250.dtsi - Fix minor issue about coding style Changes from v3: - Remove all dependency about following patchset to remove static memory mapping for SYSRAM[1] / PMU ([2] or [3]). If following patchset merged, I'll send a further patches to support SYSRAM/PMU for secondary CPU. [1] http://www.spinics.net/lists/arm-kernel/msg323011.html [2] https://lkml.org/lkml/2014/4/2/48 [3] http://www.spinics.net/lists/arm-kernel/msg316013.html Changes from v2: - Remove static memory mapping about SYSRAM/PMU such as following patches: ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250 ARM: EXYNOS: Add IO mapping for PMU of Exynos3250 - Add description for secondary CPU boot of Exynos4212/Exynos3250 - Fix description in exynos_cpu_die() to remove particular SoC series - Fix minor coding style - Add documentation for Exynos3250 clock controller Changes from v1: - Add new samsung,exynos3 compatible name - Add comment about exynos_cpu_boot in Exynos4212 - Remove unnecessary 'goto' statement in firmware.c - Use read_cpuid_part_number() function instead of assembler directly - Post separated pinctrl patch from this patchset : https://lkml.org/lkml/2014/4/13/156 - Remove unused pmu interrupts due to Exynos3250 dual-core - Cosolidate all the patches related to exynos3250.dtsi into one patch - Fix gic compatible name to cortex-a15-gic because Cortex-A7 GIC is same - Add sign-off of sender to all this patches - Fix minor typo Chanwoo Choi (3): ARM: EXYNOS: Add Exynos3250 SoC ID ARM: EXYNOS: Support secondary CPU boot of Exynos3250 dt-bindings: add documentation for Exynos3250 clock controller Tomasz Figa (2): clk: samsung: exynos3250: Add clocks using common clock framework ARM: dts: Add device tree sources for Exynos3250 .../devicetree/bindings/clock/exynos3250-clock.txt | 41 ++ arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 475 + arch/arm/boot/dts/exynos3250.dtsi | 439 arch/arm/mach-exynos/Kconfig | 22 + arch/arm/mach-exynos/common.h | 10 + arch/arm/mach-exynos/exynos.c | 2 + arch/arm/mach-exynos/firmware.c| 9 +- drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos3250.c | 782 + include/dt-bindings/clock/exynos3250.h | 258 +++ 10 files changed, 2038 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/clock/exynos3250-clock.txt create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi create mode 100644 arch/arm/boot/dts/exynos3250.dtsi create mode 100644 drivers/clk/samsung/clk-exynos3250.c create mode 100644 include/dt-bindings/clock/exynos3250.h -- 1.8.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
[PATCHv5 5/5] ARM: dts: Add device tree sources for Exynos3250
From: Tomasz Figa t.f...@samsung.com
This patch add new exynos3250.dtsi to support Exynos3250 SoC based on Cortex-A7
dual core and includes following dt nodes:
- GIC interrupt controller
- Pinctrl to control GPIOs
- Clock controller
- CPU information (Cortex-A7 dual core)
- UART to support serial port
- MCT (Multi Core Timer)
- ADC (Analog Digital Converter)
- I2C/SPI bus
- Power domain
- PMU (Performance Monitoring Unit)
- MSHC (Mobile Storage Host Controller)
- PWM (Pluse Width Modulation)
- AMBA bus
- sysram node for SYSRAM memory mapping
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Hyunhee Kim hyunhee@samsung.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: Russell King li...@arm.linux.org.uk
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 475 ++
arch/arm/boot/dts/exynos3250.dtsi | 439 +++
2 files changed, 914 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
diff --git a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
new file mode 100644
index 000..47b92c1
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
@@ -0,0 +1,475 @@
+/*
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config optiosn are listed as
device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+pinctrl_0 {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb: gpb {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpc0: gpc0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpc1: gpc1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd0: gpd0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd1: gpd1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ uart0_data: uart0-data {
+ samsung,pins = gpa0-0, gpa0-1;
+ samsung,pin-function = 0x2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart0_fctl: uart0-fctl {
+ samsung,pins = gpa0-2, gpa0-3;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart1_data: uart1-data {
+ samsung,pins = gpa0-4, gpa0-5;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ uart1_fctl: uart1-fctl {
+ samsung,pins = gpa0-6, gpa0-7;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ i2c2_bus: i2c2-bus {
+ samsung,pins = gpa0-6, gpa0-7;
+ samsung,pin-function = 3;
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 0;
+ };
+
+ i2c3_bus: i2c3-bus {
+ samsung,pins = gpa1-2, gpa1-3;
+ samsung,pin-function = 3;
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 0;
+ };
+
+ spi0_bus: spi0-bus {
+ samsung,pins = gpb-0, gpb-2, gpb-3;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 0;
+ };
[PATCHv5 4/5] dt-bindings: add documentation for Exynos3250 clock controller
The Exynos3250 clocks are statically listed and registered using the
Samsung specific common clock helper functions. Both device tree based
clock lookup and clkdev based clock lookups are supported.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Tomasz Figa t.f...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: Randy Dunlap rdun...@infradead.org
Cc: Tomasz Figa t.f...@samsung.com
---
.../devicetree/bindings/clock/exynos3250-clock.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/exynos3250-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
new file mode 100644
index 000..aadc9c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
@@ -0,0 +1,41 @@
+* Samsung Exynos3250 Clock Controller
+
+The Exynos3250 clock controller generates and supplies clock to various
+controllers within the Exynos3250 SoC.
+
+Required Properties:
+
+- compatible: should be one of the following.
+ - samsung,exynos3250-cmu - controller compatible with Exynos3250 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos3250.h header and can be used in device
+tree sources.
+
+Example 1: An example of a clock controller node is listed below.
+
+ cmu: clock-controller@1003 {
+ compatible = samsung,exynos3250-cmu;
+ reg = 0x1003 0x2;
+ #clock-cells = 1;
+ };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+ controller. Refer to the standard clock bindings for information
+ about 'clocks' and 'clock-names' property.
+
+ serial@1380 {
+ compatible = samsung,exynos4210-uart;
+ reg = 0x1380 0x100;
+ interrupts = 0 109 0;
+ clocks = cmu CLK_UART0, cmu CLK_SCLK_UART0;
+ clock-names = uart, clk_uart_baud0;
+ };
--
1.8.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
[PATCHv5 2/5] ARM: EXYNOS: Support secondary CPU boot of Exynos3250
This patch fix the offset of CPU boot address and don't need to send smc call
of SMC_CMD_CPU1BOOT command for secondary CPU boot because Exynos3250 removes
WFE in secure mode.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/firmware.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 739bdc8..eb91d23 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -30,6 +30,13 @@ static int exynos_do_idle(void)
static int exynos_cpu_boot(int cpu)
{
/*
+* Exynos3250 doesn't need to send smc command for secondary CPU boot
+* because Exynos3250 removes WFE in secure mode.
+*/
+ if (soc_is_exynos3250())
+ return 0;
+
+ /*
* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
* But, Exynos4212 has only one secondary CPU so second parameter
* isn't used for informing secure firmware about CPU id.
@@ -50,7 +57,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long
boot_addr)
boot_reg = sysram_ns_base_addr + 0x1c;
- if (!soc_is_exynos4212())
+ if (!soc_is_exynos4212() !soc_is_exynos3250())
boot_reg += 4*cpu;
__raw_writel(boot_addr, boot_reg);
--
1.8.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
[PATCHv5 3/5] clk: samsung: exynos3250: Add clocks using common clock framework
From: Tomasz Figa t.f...@samsung.com This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7 using common clock framework. The CMU (Clock Management Unit) of Exynos3250 control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses, and function clocks for individual IPs. The CMU of Exynos3250 includes following clock doamins: - CPU block for Cortex-A7 MPCore processor - LEFTBUS/RIGHTBUS block - TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Signed-off-by: Hyunhee Kim hyunhee@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Seung-Woo Kim sw0312@samsung.com Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Signed-off-by: Karol Wrona k.wr...@samsung.com Signed-off-by: YoungJun Cho yj44@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Mike Turquette mturque...@linaro.org Cc: Kukjin Kim kgene@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org --- drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos3250.c | 782 + include/dt-bindings/clock/exynos3250.h | 258 +++ 3 files changed, 1041 insertions(+) create mode 100644 drivers/clk/samsung/clk-exynos3250.c create mode 100644 include/dt-bindings/clock/exynos3250.h diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile index 2cb62f8..a859ffd 100644 --- a/drivers/clk/samsung/Makefile +++ b/drivers/clk/samsung/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o +obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o diff --git a/drivers/clk/samsung/clk-exynos3250.c b/drivers/clk/samsung/clk-exynos3250.c new file mode 100644 index 000..c0f4344 --- /dev/null +++ b/drivers/clk/samsung/clk-exynos3250.c @@ -0,0 +1,782 @@ +/* + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Common Clock Framework support for Exynos3250 SoC. + */ + +#include linux/clk.h +#include linux/clkdev.h +#include linux/clk-provider.h +#include linux/of.h +#include linux/of_address.h +#include linux/platform_device.h +#include linux/syscore_ops.h + +#include dt-bindings/clock/exynos3250.h + +#include clk.h +#include clk-pll.h + +#define SRC_LEFTBUS0x4200 +#define DIV_LEFTBUS0x4500 +#define GATE_IP_LEFTBUS0x4800 +#define SRC_RIGHTBUS 0x8200 +#define DIV_RIGHTBUS 0x8500 +#define GATE_IP_RIGHTBUS 0x8800 +#define GATE_IP_PERIR 0x8960 +#define MPLL_LOCK 0xc010 +#define MPLL_CON0 0xc110 +#define VPLL_LOCK 0xc020 +#define VPLL_CON0 0xc120 +#define UPLL_LOCK 0xc030 +#define UPLL_CON0 0xc130 +#define SRC_TOP0 0xc210 +#define SRC_TOP1 0xc214 +#define SRC_CAM0xc220 +#define SRC_MFC0xc228 +#define SRC_G3D0xc22c +#define SRC_LCD0xc234 +#define SRC_ISP0xc238 +#define SRC_FSYS 0xc240 +#define SRC_PERIL0 0xc250 +#define SRC_PERIL1 0xc254 +#define SRC_MASK_TOP 0xc310 +#define SRC_MASK_CAM 0xc320 +#define SRC_MASK_LCD 0xc334 +#define SRC_MASK_ISP 0xc338 +#define SRC_MASK_FSYS 0xc340 +#define SRC_MASK_PERIL00xc350 +#define SRC_MASK_PERIL10xc354 +#define DIV_TOP0xc510 +#define DIV_CAM0xc520 +#define DIV_MFC0xc528 +#define DIV_G3D0xc52c +#define DIV_LCD0xc534 +#define DIV_ISP0xc538 +#define DIV_FSYS0 0xc540 +#define DIV_FSYS1 0xc544 +#define DIV_FSYS2 0xc548 +#define DIV_PERIL0 0xc550 +#define DIV_PERIL1 0xc554 +#define DIV_PERIL3 0xc55c +#define DIV_PERIL4 0xc560 +#define DIV_PERIL5 0xc564 +#define DIV_CAM1 0xc568 +#define CLKDIV2_RATIO 0xc580 +#define GATE_SCLK_CAM 0xc820 +#define GATE_SCLK_MFC 0xc828 +#define GATE_SCLK_G3D 0xc82c +#define GATE_SCLK_LCD 0xc834 +#define GATE_SCLK_ISP_TOP 0xc838 +#define GATE_SCLK_FSYS 0xc840
[PATCHv5 1/5] ARM: EXYNOS: Add Exynos3250 SoC ID
This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that
is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses Cortex-A7
dual cores and has a target speed of 1.0GHz.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/Kconfig | 22 ++
arch/arm/mach-exynos/common.h | 10 ++
arch/arm/mach-exynos/exynos.c | 2 ++
3 files changed, 34 insertions(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..6da8a68 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -11,6 +11,17 @@ if ARCH_EXYNOS
menu SAMSUNG EXYNOS SoCs Support
+config ARCH_EXYNOS3
+ bool SAMSUNG EXYNOS3
+ select ARM_AMBA
+ select CLKSRC_OF
+ select HAVE_ARM_SCU if SMP
+ select HAVE_SMP
+ select PINCTRL
+ select PM_GENERIC_DOMAINS if PM_RUNTIME
+ help
+ Samsung EXYNOS3 SoCs based systems
+
config ARCH_EXYNOS4
bool SAMSUNG EXYNOS4
default y
@@ -41,6 +52,17 @@ config ARCH_EXYNOS5
comment EXYNOS SoCs
+config SOC_EXYNOS3250
+ bool SAMSUNG EXYNOS3250
+ default y
+ depends on ARCH_EXYNOS3
+ select ARCH_HAS_BANDGAP
+ select ARM_CPU_SUSPEND if PM
+ select PINCTRL_EXYNOS
+ select SAMSUNG_DMADEV
+ help
+ Enable EXYNOS3250 CPU support
+
config CPU_EXYNOS4210
bool SAMSUNG EXYNOS4210
default y
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 278b573..fb43ff4 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -15,6 +15,9 @@
#include linux/reboot.h
#include linux/of.h
+#define EXYNOS3250_SOC_ID 0xE3472000
+#define EXYNOS3_SOC_MASK0xF000
+
#define EXYNOS4210_CPU_ID 0x4321
#define EXYNOS4212_CPU_ID 0x4322
#define EXYNOS4412_CPU_ID 0xE4412200
@@ -33,6 +36,7 @@ static inline int is_samsung_##name(void) \
return ((samsung_cpu_id mask) == (id mask));\
}
+IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
@@ -40,6 +44,12 @@ IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID,
EXYNOS5_SOC_MASK)
IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS5_SOC_MASK)
IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK)
+#if defined(CONFIG_SOC_EXYNOS3250)
+# define soc_is_exynos3250()is_samsung_exynos3250()
+#else
+# define soc_is_exynos3250()0
+#endif
+
#if defined(CONFIG_CPU_EXYNOS4210)
# define soc_is_exynos4210() is_samsung_exynos4210()
#else
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 4df3452..f2b8e80 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -293,6 +293,8 @@ static void __init exynos_dt_machine_init(void)
}
static char const *exynos_dt_compat[] __initconst = {
+ samsung,exynos3,
+ samsung,exynos3250,
samsung,exynos4,
samsung,exynos4210,
samsung,exynos4212,
--
1.8.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 v13 00/19] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
On Mon, May 12, 2014 at 3:37 PM, Arnd Bergmann a...@arndb.de wrote: On Monday 12 May 2014 11:44:45 Shaik Ameer Basha wrote: This is the subset of previous v12 series and includes only the fixes and enhancements, leaving out the private DT bindings as discussed in the below thread. -- http://www.gossamer-threads.com/lists/linux/kernel/1918178 This patch series includes, 1] fixes for exynos-iommu driver build break 2] includes several bug fixes and enhancements for the exynos-iommu driver 3] code to handle multiple exynos sysmmu versions 4] adding support for device tree Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt The patches look good to me, but please add a note into the samsung,sysmmu.txt file explaining that the binding is incomplete and that it's possible to change in incompatible ways when we add support for attaching devices to the IOMMU through the generic IOMMU binding. Hi Arnd, Thank you. If there are no more comments on this series, I can send one more incremental patch with the note mentioned in your review comment. Hi Joerg Roedel, Can you please add this series to your tree. Regards, Shaik Ameer Basha Arnd ___ iommu mailing list io...@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu -- 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] ARM: exynos4212: hotplug: Fix CPU idle clock down after CPU1 off
On Exynos4212 USE_DELAYED_RESET_ASSERTION must be set in
ARM_CORE1_OPTION register during CPU power down. This is the proper way
of powering down CPU. Additionally without this the CPU clock down won't
work after powering down CPU1 and CPU will work at full frequency chosen
by CPUfreq governor.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/mach-exynos/hotplug.c | 28 +---
arch/arm/mach-exynos/regs-pmu.h | 2 ++
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead530c6f8..59b813e74558 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -74,7 +74,7 @@ static inline void cpu_enter_lowpower_a15(void)
dsb();
}
-static inline void cpu_leave_lowpower(void)
+static inline void cpu_leave_lowpower(unsigned int cpu)
{
unsigned int v;
@@ -88,6 +88,14 @@ static inline void cpu_leave_lowpower(void)
: =r (v)
: Ir (CR_C), Ir (0x40)
: cc);
+
+ if (cpu == 1 soc_is_exynos4212()) {
+ unsigned int tmp;
+
+ tmp = __raw_readl(S5P_ARM_CORE1_OPTION);
+ tmp = ~(S5P_USE_DELAYED_RESET_ASSERTION);
+ __raw_writel(tmp, S5P_ARM_CORE1_OPTION);
+ }
}
static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
@@ -95,8 +103,22 @@ static inline void platform_do_lowpower(unsigned int cpu,
int *spurious)
for (;;) {
/* make cpu1 to be turned off at next WFI command */
- if (cpu == 1)
+ if (cpu == 1) {
+ if (soc_is_exynos4212()) {
+ unsigned int tmp;
+
+ /*
+* Exynos 4212 requires setting
+* USE_DELAYED_RESET_ASSERTION so the CPU idle
+* clock down feature could properly detect
+* global idle state when CPU1 is off.
+*/
+ tmp = __raw_readl(S5P_ARM_CORE1_OPTION);
+ tmp |= S5P_USE_DELAYED_RESET_ASSERTION;
+ __raw_writel(tmp, S5P_ARM_CORE1_OPTION);
+ }
__raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
+ }
/*
* here's the WFI
@@ -152,7 +174,7 @@ void __ref exynos_cpu_die(unsigned int cpu)
* bring this CPU back into the world of cache
* coherency, and then restore interrupts
*/
- cpu_leave_lowpower();
+ cpu_leave_lowpower(cpu);
if (spurious)
pr_warn(CPU%u: %u spurious wakeup calls\n, cpu, spurious);
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 4f6a2560d022..1a3da4ef0e22 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -25,6 +25,7 @@
#define S5P_USE_STANDBY_WFI0 (1 16)
#define S5P_USE_STANDBY_WFE0 (1 24)
+#define S5P_USE_DELAYED_RESET_ASSERTIONBIT(12)
#define EXYNOS_SWRESET S5P_PMUREG(0x0400)
#define EXYNOS5440_SWRESET S5P_PMUREG(0x00C4)
@@ -107,6 +108,7 @@
#define S5P_ARM_CORE1_CONFIGURATIONS5P_PMUREG(0x2080)
#define S5P_ARM_CORE1_STATUS S5P_PMUREG(0x2084)
+#define S5P_ARM_CORE1_OPTION S5P_PMUREG(0x2088)
#define S5P_PAD_RET_MAUDIO_OPTION S5P_PMUREG(0x3028)
#define S5P_PAD_RET_GPIO_OPTIONS5P_PMUREG(0x3108)
--
1.9.1
--
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] mmc: dw_mmc: Make sure we don't get stuck when we get an error
Seungwon, On Mon, May 12, 2014 at 9:52 PM, Seungwon Jeon tgih@samsung.com wrote: Hi Doug, On Tue, May 13, 2014, Doug Anderson wrote: Seungwon, On Sat, May 10, 2014 at 7:11 AM, Seungwon Jeon tgih@samsung.com wrote: On Fri, May 09, 2014, Sonny Rao wrote: On Thu, May 8, 2014 at 2:42 AM, Yuvaraj Kumar yuvaraj...@gmail.com wrote: Any comments on this patch? I'll just add that without this fix, running the tuning loop for UHS modes is not reliable on dw_mmc because errors will happen and you will eventually hit this race and hang. This can happen any time there is tuning like during boot or during resume from suspend. On Thu, Mar 27, 2014 at 11:48 AM, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote: From: Doug Anderson diand...@chromium.org If we happened to get a data error at just the wrong time the dw_mmc driver could get into a state where it would never complete its request. That would leave the caller just hanging there. We fix this two ways and both of the two fixes on their own appear to fix the problems we've seen: 1. Fix a race in the tasklet where the interrupt setting the data error happens _just after_ we check for it, then we get a EVENT_XFER_COMPLETE. We fix this by repeating a bit of code. I think repeating is not good approach to fix race. In your case, XFER_COMPLETE preceded data error and DTO didn't come? It seems strange case. I want to know actual error value if you can reproduce. XFER_COMPLETE didn't necessarily precede data error. Imagine this scenario: 1. Check for data error: nope 2. Interrupt happens and we get a data error and immediately xfer complete 3. Check for xfer complete: yup That's the state that we are handling. The system that dw_mmc uses where the interrupt handler has no locking makes it incredibly difficult to get things right. Can you propose an alternate fix that would avoid the race? Thank you for detailed scenario. You're right. Have you consider using spin_lock() in interrupt handler? Then, we'll need to change spin_lock() to spin_lock_irqsave() in tasklet func. And other locks in driver may need to be adjusted properly. I have certainly considered it and I think it's the right way to go, but I believe that this would be a pretty massive change to the design of dw_mmc. Someone appeared to try very hard not to use a spinlock in the interrupt handler and came up with the whole tasklet / pending events / completed events to deal with it. In this particular case it would be pretty easy to just add the spinlock around the data error / xfer complete checks, though once we have a spinlock here it seems like we'd want to start using it in other places. It would be confusing if the interrupt handler grabbed a spinlock the whole time but then only used it to protect a single small check. I'm really curious, though, why this driver can't just use a threaded irq handler and eliminate the whole interrupt / tasklet split. That seems saner in the long run. To return above scenario: 1. Check for data error: nope 2. Check for xfer complete: nope - escape tasklet. 3. Interrupt happens and we get a data error and immediately xfer complete 4. Check for data error (Again in tasklet) : yup How about this change? I'm not sure I understand. Are you suggesting a change to my code, or wondering how my code handles the above scenario? I think your scenario works find either with or without my patch. -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: [PATCHv4 5/7] clk: samsung: exynos3250: Add clocks using common clock framework
Hi Chanwoo, On 13.05.2014 13:49, Chanwoo Choi wrote: Hi Tomasz, On 04/26/2014 09:39 AM, Tomasz Figa wrote: Hi Chanwoo, On 25.04.2014 03:16, Chanwoo Choi wrote: From: Tomasz Figa t.f...@samsung.com This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7 using common clock framework. The CMU (Clock Management Unit) of Exynos3250 control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses, and function clocks for individual IPs. The CMU of Exynos3250 includes following clock doamins: - CPU block for Cortex-A7 MPCore processor - LEFTBUS/RIGHTBUS block - TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR In original driver present in our internal tree I have separated several CMUs to account for certain factors caused by hardware design, which require such separation. Is there any reason why they were merged together into a single CMU again? This patch just include clocks in CMU clocks without CMU_DMC/CMU_ISP. I'll send a further patches to support CMU_DMC/CMU_ISP after verifying it. Cc: Mike Turquette mturque...@linaro.org Cc: Kukjin Kim kgene@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Signed-off-by: Hyunhee Kim hyunhee@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Seung-Woo Kim sw0312@samsung.com Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Signed-off-by: Karol Wrona k.wr...@samsung.com Signed-off-by: YoungJun Cho yj44@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos3250.c | 785 + include/dt-bindings/clock/exynos3250.h | 256 +++ 3 files changed, 1042 insertions(+) create mode 100644 drivers/clk/samsung/clk-exynos3250.c create mode 100644 include/dt-bindings/clock/exynos3250.h diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile index 8eb4799..d120797 100644 --- a/drivers/clk/samsung/Makefile +++ b/drivers/clk/samsung/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_COMMON_CLK)+= clk.o clk-pll.o +obj-$(CONFIG_SOC_EXYNOS3250)+= clk-exynos3250.o obj-$(CONFIG_ARCH_EXYNOS4)+= clk-exynos4.o obj-$(CONFIG_SOC_EXYNOS5250)+= clk-exynos5250.o obj-$(CONFIG_SOC_EXYNOS5420)+= clk-exynos5420.o diff --git a/drivers/clk/samsung/clk-exynos3250.c b/drivers/clk/samsung/clk-exynos3250.c new file mode 100644 index 000..0574a76 --- /dev/null +++ b/drivers/clk/samsung/clk-exynos3250.c @@ -0,0 +1,785 @@ +/* + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Common Clock Framework support for Exynos3250 SoC. + */ + +#include linux/clk.h +#include linux/clkdev.h +#include linux/clk-provider.h +#include linux/of.h +#include linux/of_address.h +#include linux/platform_device.h +#include linux/syscore_ops.h + +#include dt-bindings/clock/exynos3250.h + +#include clk.h +#include clk-pll.h + +#define SRC_LEFTBUS0x4200 +#define DIV_LEFTBUS0x4500 +#define GATE_IP_LEFTBUS0x4800 +#define SRC_RIGHTBUS0x8200 +#define DIV_RIGHTBUS0x8500 +#define GATE_IP_RIGHTBUS0x8800 +#define GATE_IP_PERIR0x8960 +#define MPLL_LOCK0xc010 +#define MPLL_CON00xc110 +#define VPLL_LOCK0xc020 +#define VPLL_CON00xc120 +#define UPLL_LOCK0xc030 +#define UPLL_CON00xc130 +#define SRC_TOP00xc210 +#define SRC_TOP10xc214 +#define SRC_CAM0xc220 +#define SRC_MFC0xc228 +#define SRC_G3D0xc22c +#define SRC_LCD0xc234 +#define SRC_ISP0xc238 +#define SRC_FSYS0xc240 +#define SRC_PERIL00xc250 +#define SRC_PERIL10xc254 +#define SRC_MASK_TOP0xc310 +#define SRC_MASK_CAM0xc320 +#define SRC_MASK_LCD0xc334 +#define SRC_MASK_ISP0xc338 +#define SRC_MASK_FSYS0xc340 +#define SRC_MASK_PERIL00xc350 +#define SRC_MASK_PERIL10xc354 +#define DIV_TOP0xc510 +#define DIV_CAM0xc520 +#define DIV_MFC0xc528 +#define DIV_G3D0xc52c +#define DIV_LCD0xc534 +#define DIV_ISP0xc538 +#define DIV_FSYS00xc540 +#define DIV_FSYS10xc544 +#define DIV_FSYS20xc548 +#define DIV_PERIL00xc550 +#define DIV_PERIL10xc554 +#define DIV_PERIL3
Re: [PATCH v6 5/5] arm: exynos: Add MCPM call-back functions
On Tue, May 13, 2014 at 12:58:44PM +0100, Abhilash Kesavan wrote:
[...]
+static int __init exynos_mcpm_init(void)
+{
+ struct device_node *node;
+ int ret = 0;
There is no point in initializing it to 0.
+
+ node = of_find_compatible_node(NULL, NULL, samsung,exynos5420);
+ if (!node)
+ return -ENODEV;
+ of_node_put(node);
+
+ if (!cci_probed())
+ return -ENODEV;
+
+ node = of_find_compatible_node(NULL, NULL,
+ samsung,exynos4210-sysram-ns);
+ if (!node)
+ return -ENODEV;
+
+ ns_sram_base_addr = of_iomap(node, 0);
+ of_node_put(node);
+ if (!ns_sram_base_addr) {
+ pr_err(failed to map non-secure iRAM base address\n);
+ return -ENOMEM;
+ }
+
+ /*
+* To increase the stability of KFC reset we need to program
+* the PMU SPARE3 register
+*/
+ __raw_writel(EXYNOS5420_SWRESET_KFC_SEL, S5P_PMU_SPARE3);
+
+ exynos_mcpm_usage_count_init();
+
+ ret = mcpm_platform_register(exynos_power_ops);
+ if (!ret)
+ ret = mcpm_sync_init(exynos_pm_power_up_setup);
+ if (ret) {
+ iounmap(ns_sram_base_addr);
+ return ret;
+ }
+
+ mcpm_smp_set_ops();
+
+ pr_info(Exynos MCPM support installed\n);
+
+ /*
+* Future entries into the kernel can now go
+* through the cluster entry vectors.
+*/
+ __raw_writel(virt_to_phys(mcpm_entry_point),
+ ns_sram_base_addr + MCPM_BOOT_ADDR_OFFSET);
+
ns_sram_base_addr must be unmapped, since it is unused after the write.
Lorenzo
+ return ret;
+}
+
+early_initcall(exynos_mcpm_init);
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index f6b68a3..4179f6a 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -38,6 +38,7 @@
#define S5P_INFORM5S5P_PMUREG(0x0814)
#define S5P_INFORM6S5P_PMUREG(0x0818)
#define S5P_INFORM7S5P_PMUREG(0x081C)
+#define S5P_PMU_SPARE3 S5P_PMUREG(0x090C)
#define S5P_ARM_CORE0_LOWPWR S5P_PMUREG(0x1000)
#define S5P_DIS_IRQ_CORE0 S5P_PMUREG(0x1004)
@@ -322,4 +323,6 @@
#define EXYNOS5_OPTION_USE_RETENTION (1 4)
+#define EXYNOS5420_SWRESET_KFC_SEL 0x3
+
#endif /* __ASM_ARCH_REGS_PMU_H */
--
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: [RFC V3 2/3] drm/bridge: add a dummy panel driver to support lvds bridges
On Tue, May 13, 2014 at 1:35 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Fri, May 09, 2014 at 08:23:01PM +0530, Ajay Kumar wrote:
implement basic panel controls as a drm_bridge so that
the existing bridges can make use of it.
The driver assumes that it is the last entity in the bridge chain.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../bindings/drm/bridge/bridge_panel.txt | 45
Can we please stop adding files to this directory? Device tree bindings
are supposed to be OS agnostic, but DRM is specific to Linux and should
not be used when describing hardware.
One should not be adding a devicetree node if it is not describing the
actual hardware?
diff --git a/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt
b/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt
[...]
+ -led-en-gpio:
+ eDP panel LED enable GPIO.
+ Indicates which GPIO needs to be powered up as output
+ to enable the backlight.
Since this is used to control a backlight, then this should really be a
separate node to describe the backlight device (and use the
corresponding backlight driver) rather than duplicating a subset of that
functionality.
I am stressing this point again!
Backlight should ideally be enabled only after:
1) Panel is powered up (LCD_VDD)
2) HPD is thrown.
3) Valid data starts coming from the encoder(DP in our case)
All the above 3 are controlled inside drm, but pwm-backlight is
independent of drm. So, we let the pwm_config happen in pwm-backlight driver
and enable backlight GPIO(BL_EN) inside drm, after valid video data starts
coming out of the encoder.
As you said, we can get this GPIO from a backlight device node, but since
this GPIO is related to panel also, I think conceptually its not wrong
to have this
GPIO binding defined in a panel node.
+ -panel-pre-enable-delay:
+ delay value in ms required for panel_pre_enable process
+ Delay in ms needed for the eDP panel LCD unit to
+ powerup, and delay needed between panel_VCC and
+ video_enable.
What are panel_VCC or video_enable?
It is the time taken for the panel to throw a valid HPD from the point
we enabled LCD_VCC.
After HPD is thrown, we can start sending video data.
+ -panel-enable-delay:
+ delay value in ms required for panel_enable process
+ Delay in ms needed for the eDP panel backlight/LED unit
+ to powerup, and delay needed between video_enable and
+ BL_EN.
Similarily, what does BL_EN stand for?
Backlight Enable, same as enable-gpios in pwm-backlight driver.
+ bridge-panel {
+ compatible = drm-bridge,panel;
Again, drm- doesn't mean anything outside of Linux (and maybe BSD),
therefore shouldn't be used to describe hardware in device tree.
Agreed. :)
diff --git a/drivers/gpu/drm/bridge/bridge_panel.c
b/drivers/gpu/drm/bridge/bridge_panel.c
[...]
This duplicates much of the functionality that panels should provide. I
think a better solution would be to properly integrate panels with
bridges.
True, ideally I should be calling drm_panel functions from a simple dummy bridge
which sits at the end of the bridge chain. But, since you are not
convinced with having
pre_enable and post_disable calls for panels, I had no other way to do
this, than
stuffing these panel controls inside bridge! :(
See the discussion here. I have already explained this!
http://www.spinics.net/lists/dri-devel/msg57973.html
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 v4 5/5] mcpm: exynos: populate suspend and powered_up callbacks
On Tue, May 13, 2014 at 12:43:31PM +0100, Chander Kashyap wrote:
[...]
+static void exynos_suspend(u64 residency)
+{
+ unsigned int mpidr, cpunr;
+
+ mpidr = read_cpuid_mpidr();
+ cpunr = exynos_pmu_cpunr(mpidr);
If I were to be picky, I would compute these values only if they
are needed, ie move the computation after exynos_power_down().
Yes thats make sense. I will realign it.
There is another quite horrible issue here. We know this code works
because the processors A15/A7 hit the caches with C bit in SCTLR cleared.
On processors where this is not true, this sequence would explode
if power down fails (in case core is gated but L2 is still powered on,
the stack is stuck in L2) since it is going to read stack data that is
in L2 but can't be read.
It is not related to this sequence only, but it is an issue in general
and wanted to mention that on the lists for public awareness.
Can you please elaborate. I didn't understand.
It is not related to this patch only. This function carries out writes to the
stack (which might end up in eg L2) and then disables the C bit in SCTLR
through MCPM.
A15 and A7 processors hit the cache with the C bit clear in the SCTLR
so the processor still hits the stack values if the power down fails.
On processors where caches are not hit with the C bit clear (eg A9) this code
would fail since the stack values that sit in the caches cannot be read with
the C bit clear in SCTLR until the SCTLR is restored, so it will have to
be implemented in assembly with no stack usage (or better, no cacheable data
usage).
So, all I am saying is, to avoid copy'n'paste havoc and to avoid running
this code on Exynos platforms where it must not be run as-is, please add
a comment along the line:
This function requires the stack data to be visible through power down
and can only be executed on processors like A15 and A7 that hit the cache
with the C bit clear in the SCTLR register.
Please let me know if that's clear.
Lorenzo
The gist of what I am saying is, please add a comment to that extent,
here and it should be added in exynos_power_down() too.
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr +
0x1c);
No magic numbers please (0x1c). You can add a macro/wrapper, as TC2 does.
Yes i will remove it.
+ exynos_power_down();
+
+ /*
+ * Execution reaches here only if cpu did not power down.
+ * Hence roll back the changes done in exynos_power_down function.
+ */
+ exynos_cpu_powerup(cpunr);
Please be aware that if this function returns MCPM will soft reboot, and
the CPUidle driver will have no way to detect a state entry failure.
I am just flagging this up, since fixing this behaviour is not easy, and
honestly, since power down failure should be the exception not the rule,
the idle stats should not be affected much.
I think this is the proper way of implementing the sequence but please
all keep in mind what I wrote above.
Lorenzo
+}
+
static const struct mcpm_platform_ops exynos_power_ops = {
.power_up = exynos_power_up,
.power_down = exynos_power_down,
.power_down_finish = exynos_power_down_finish,
+ .suspend= exynos_suspend,
+ .powered_up = exynos_powered_up,
};
static void __init exynos_mcpm_usage_count_init(void)
--
1.7.9.5
--
with warm regards,
Chander Kashyap
--
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 v13 00/19] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
On Mon, May 12, 2014 at 11:44:45AM +0530, Shaik Ameer Basha wrote: Cho KyongHo (18): iommu/exynos: fix build errors iommu/exynos: change error handling when page table update is failed iommu/exynos: allocate lv2 page table from own slab iommu/exynos: fix L2TLB invalidation iommu/exynos: remove prefetch buffer setting iommu/exynos: add missing cache flush for removed page table entries iommu/exynos: always enable runtime PM iommu/exynos: remove dbgname from drvdata of a System MMU iommu/exynos: use managed device helper functions iommu/exynos: gating clocks of master H/W iommu/exynos: remove custom fault handler iommu/exynos: change rwlock to spinlock iommu/exynos: use exynos-iommu specific typedef iommu/exynos: enhanced error messages documentation: iommu: add binding document of Exynos System MMU iommu/exynos: support for device tree iommu/exynos: turn on useful configuration options iommu/exynos: apply workaround of caching fault page table entries .../devicetree/bindings/iommu/samsung,sysmmu.txt | 65 ++ drivers/iommu/exynos-iommu.c | 1035 2 files changed, 677 insertions(+), 423 deletions(-) create mode 100644 Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt Applied, thanks. Please send another patch to update the documentation as requested by Arnd. Joerg -- 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/5] MCPM backend for Exynos5420
On Tue, 13 May 2014, Abhilash Kesavan wrote:
This is v6 of the series adding MCPM backend support for SMP secondary boot
and core switching on Samsung's Exynos5420. The patches are based on the mcpm
support added for Exynos5420 in the Chromium kernel repository here:
https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/chromeos-3.8
The patches have been prepared on Kukjin Kim's for-next branch and tested on
SMDK5420 EVT1 as well as an exynos5420 based chromebook (peach-pit) using the
/dev/b.L_switcher user interface. Secondary core boot-up has also been
tested
on both the boards.
OK... Now it is time for real testing. :-)
The /dev/b.L_switcher interface tests the switcher. Here you really
want to hammer the MCPM functionalities and especially your backend code
as hard as possible. I therefore recommend the following test script:
-- 8
#!/bin/bash
echo 0 /sys/kernel/bL_switcher/active
sleep 1
pids=
for cpu in /sys/devices/system/cpu/cpu?/online; do
{ cpu_nr=${cpu:27:1}
while true; do
echo 1 $cpu 2 /dev/null
sleep .00$RANDOM
val1=$(cat $cpu)
echo 0 $cpu 2 /dev/null
sleep .00$RANDOM
val0=$(cat $cpu)
[ $val1 = 1 -a $val0 = 0 ] echo -n $cpu_nr
done
}
pids=$pids $!
done
trap kill $pids; echo 0 15
wait $pids
-- 8
Leave this running for a couple hours making sure you see all CPU
numbers being printed. The printing order will be random, but each CPU
number should continuously appear.
Nicolas
--
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 5/6] ARM: EXYNOS: Enable multi-platform build support
On Tue, May 13, 2014 at 2:15 AM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 13 May 2014 13:37:33 Kukjin Kim wrote: Arnd Bergmann wrote: On Tuesday 22 April 2014, Olof Johansson wrote: I don't think there's a point in keeping this around. A single-platform config is just enabling a single platform in the config, it's not a specific option. I don't think any of the other platforms use anything like this today. The only one doing that is shmobile, but only because they have some SoCs that are multiplatform capable and some that are not. This isn't the case for Exynos, so it should no longer be needed. When I originally created this patch 18 months ago, there were a number of drivers that broke when multiplatform got enabled. Now the cpufreq driver is the only one left, but it seems that it will make it for 3.16, and I wouldn't wait for it if it doesn't. Let's just do multiplatform-only. In my position in S.LSI, I'd like to keep the current ARCH_EXYNOS4 and EXYNOS5 because IMHO selecting each series would be helpful on real product, multiplatform is available though. Additionally EXYNOS3 is being added. It's true we can support exynos-multiplatform even though above options are included... I think we are talking about different questions here: What Olof and I mean is we don't want to have an ARCH_EXYNOS_SINGLE option that is there for building EXYNOS but not allowing any other SoC. Yes. i.e. the only way forward is multiplatform _only_. _BUT_ you can choose to disable all other platforms in a kernel, and thus turn it into a single-platform build. That's fine. What we don't want is added logic like the EXYNOS_SINGLE Kconfig was, just to do that. What I think you mean is that you want the individual EXYNOS versions to be separate Kconfig options, so you can build a kernel that supports EXYNOS4 but not EXYNOS5 if you want to. This is totally fine as far as I'm concerned, and it's not directly related to the first point. I'm also OK with that, but please don't make it more granular than per family if you can avoid it. Note that if you enable LPAE, you will still only be able to build EXYNOS5 after the patch, but then you can have it in the same kernel as e.g. Tegra4 and Snapdragon 600. Yep, and that's as expected. -Olof -- 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] PM / OPP: move cpufreq specific helpers out of OPP layer
On Mon, May 5, 2014 at 7:03 PM, Nishanth Menon n...@ti.com wrote: CPUFreq usage of OPP should be independent of the ordering of type of data storage inside OPP layer. The current operations can equally be performed by generic operations. [RFC]: https://patchwork.kernel.org/patch/4100811/ Series based on: v3.15-rc1 Nishanth Menon (2): PM / OPP: Remove cpufreq wrapper dependency on internal data organization PM / OPP: Move cpufreq specific OPP functions out of generic OPP library Documentation/cpu-freq/core.txt | 29 +++ Documentation/power/opp.txt | 40 ++ drivers/base/power/opp.c| 91 drivers/cpufreq/Makefile|2 + drivers/cpufreq/cpufreq_opp.c | 110 +++ include/linux/cpufreq.h | 21 include/linux/pm_opp.h | 20 --- 7 files changed, 167 insertions(+), 146 deletions(-) create mode 100644 drivers/cpufreq/cpufreq_opp.c Works fine on Exynos. Tested-by: Thomas Abraham thomas...@samsung.com -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-pm 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
[PATCH v3 0/2] cpufreq: opp: Add device tree based lookup of boost mode frequency
Changes since v2: - Reworked based on the PM / OPP: move cpufreq specific helpers out of OPP layer patch series posted by Nishanth Menon n...@ti.com. Changes since v1: - Boost mode frequencies are specfied as a set of frequencies instead of specifying them as OPPs. Thanks to Nishanth, Lukasz and Rob for the feedback. Commit 6f19efc0 (cpufreq: Add boost frequency support in core) adds support for CPU boost mode for CPUfreq drivers. To use the new boost mode, CPUfreq drivers have to specify the boost mode frequency and voltage within the CPUfreq driver, which is the case for Exynos4x12 CPUfreq driver. But for CPUfreq drivers which obtain the OPPs from cpus node, this patch series adds support to specify boost mode frequencies in the cpu device tree node. This requirement came up when Lukasz pointed out the regression caused by the Exynos CPUfreq driver consolidation patches. Thomas Abraham (2): cpufreq / OPP: Allow boost frequency to be looked up from device tree Documentation: devicetree: Add boost-frequency binding to list boost mode frequency .../devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 ++ drivers/cpufreq/cpufreq_opp.c | 39 2 files changed, 50 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt -- 1.7.4.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
[PATCH v3 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
From: Thomas Abraham thomas...@samsung.com
Commit 6f19efc0 (cpufreq: Add boost frequency support in core) adds
support for CPU boost mode. This patch adds support for finding available
boost frequencies from device tree and marking them as usable in boost mode.
Cc: Nishanth Menon n...@ti.com
Cc: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
drivers/cpufreq/cpufreq_opp.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
index c0c6f4a..e3c97f3 100644
--- a/drivers/cpufreq/cpufreq_opp.c
+++ b/drivers/cpufreq/cpufreq_opp.c
@@ -19,6 +19,7 @@
#include linux/pm_opp.h
#include linux/rcupdate.h
#include linux/slab.h
+#include linux/of.h
/**
* dev_pm_opp_init_cpufreq_table() - create a cpufreq table for a device
@@ -51,6 +52,10 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table *freq_table = NULL;
int i, max_opps, ret = 0;
unsigned long rate;
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ int j, len;
+ u32 *boost_freqs = NULL;
+#endif
rcu_read_lock();
@@ -82,6 +87,40 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
*table = freq_table[0];
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ if (of_find_property(dev-of_node, boost-frequency, len)) {
+ if (len == 0 || (len (sizeof(u32) - 1)) != 0) {
+ dev_err(dev, %s: invalid boost frequency\n, __func__);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ boost_freqs = kzalloc(len, GFP_KERNEL);
+ if (!boost_freqs) {
+ dev_warn(dev, %s: no memory for boost freq table\n,
+ __func__);
+ ret = -ENOMEM;
+ goto out;
+ }
+ of_property_read_u32_array(dev-of_node, boost-frequency,
+ boost_freqs, len / sizeof(u32));
+ }
+
+ for (j = 0; j len / sizeof(u32) boost_freqs; j++) {
+ for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
+ if (boost_freqs[j] == freq_table[i].frequency) {
+ freq_table[i].flags |= CPUFREQ_BOOST_FREQ;
+ break;
+ }
+ }
+ if (freq_table[i].frequency == CPUFREQ_TABLE_END)
+ pr_err(%s: invalid boost frequency %d\n,
+ __func__, boost_freqs[j]);
+ }
+
+ kfree(boost_freqs);
+#endif
+
out:
rcu_read_unlock();
if (ret)
--
1.7.4.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
[PATCH v3 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Thomas Abraham thomas...@samsung.com Add a new optional boost-frequency binding for specifying the frequencies usable in boost mode. Cc: Nishanth Menon n...@ti.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Signed-off-by: Thomas Abraham thomas...@samsung.com --- .../devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt new file mode 100644 index 000..d925e38 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt @@ -0,0 +1,11 @@ +* Device tree binding for CPU boost frequency (aka over-clocking) + +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as +overclocking) in which the CPU can operate in frequencies beyond the normal +operating conditions. + +Optional Properties: +- boost-frequency: list of frequencies in KHz to be used only in boost mode. + This list should be a subset of frequencies listed in operating-points + property. Refer to Documentation/devicetree/bindings/power/opp.txt for + details about operating-points property. -- 1.7.4.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
[PATCH v4 0/8] cpufreq: use cpufreq-cpu0 driver for exynos based platforms
Changes since v3: - Addressed comments from Tomasz Figa t.f...@samsung.com [http://www.spinics.net/lists/cpufreq/msg09290.html] - Rebased to v3.15-rc4 Changes since v2: - Safe operating voltage is not required while switching APLL frequency since the temporary parent's clock is divided down to keep armclk within permissible limits. Thanks to Heiko Stübner he...@sntech.de for this suggesting this. - Rob had suggested to use max frequency for each of the divider clock outputs instead of divider values. But due to certain SoC specific characteristics, the divider values corresponding to the input clock frequency for the CMU_CPU clock blocks have to be used. Changes since v1: - Removes Exynos4x12 and Exynos5250 cpufreq driver also. - Device tree based clock configuration lookup as suggested by Lukasz Majewski and Tomasz Figa. - safe operating point binding reworked as suggested by Shawn Guo. The patch series removes the use of Exynos specific cpufreq driver and enables the use of cpufreq-cpu0 driver for Exynos4210, Exynos4x12 and Exynos5250 based platforms. This is being done for few reasons. (a) The Exynos cpufreq driver reads/writes clock controller registers bypassing the Exynos CCF driver which is sort of problematic. (b) Removes the need for having clock controller register definitions in the cpufreq driver and also removes the need for statically io-remapping clock controller address space (helps in moving towards multiplatform kernel). Thomas Abraham (8): cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies clk: samsung: change scope of samsung clock lock to global clk: samsung: add infrastructure to register cpu clocks Documentation: devicetree: add cpu clock configuration data binding for Exynos4/5 clk: exynos: use cpu-clock provider type to represent arm clock ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data ARM: Exynos: switch to using generic cpufreq-cpu0 driver cpufreq: exynos: remove all exynos specific cpufreq driver support .../devicetree/bindings/clock/exynos4-clock.txt| 37 ++ .../devicetree/bindings/clock/exynos5250-clock.txt | 36 ++ .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |2 + arch/arm/boot/dts/exynos4210-origen.dts|6 + arch/arm/boot/dts/exynos4210-trats.dts |6 + arch/arm/boot/dts/exynos4210-universal_c210.dts|6 + arch/arm/boot/dts/exynos4210.dtsi | 35 ++ arch/arm/boot/dts/exynos4212.dtsi | 18 + arch/arm/boot/dts/exynos4412-odroidx.dts |6 + arch/arm/boot/dts/exynos4412-origen.dts|6 + arch/arm/boot/dts/exynos4412-trats2.dts|6 + arch/arm/boot/dts/exynos4412.dtsi | 31 ++ arch/arm/boot/dts/exynos4x12.dtsi | 36 ++ arch/arm/boot/dts/exynos5250-arndale.dts |6 + arch/arm/boot/dts/exynos5250-cros-common.dtsi |6 + arch/arm/boot/dts/exynos5250-smdk5250.dts |6 + arch/arm/boot/dts/exynos5250.dtsi | 41 ++ arch/arm/mach-exynos/exynos.c |4 +- drivers/clk/samsung/Makefile |2 +- drivers/clk/samsung/clk-cpu.c | 458 drivers/clk/samsung/clk-exynos4.c | 25 +- drivers/clk/samsung/clk-exynos5250.c | 12 +- drivers/clk/samsung/clk.c | 13 +- drivers/clk/samsung/clk.h |7 + drivers/cpufreq/Kconfig| 11 + drivers/cpufreq/Kconfig.arm| 52 --- drivers/cpufreq/Makefile |4 - drivers/cpufreq/cpufreq-cpu0.c |5 + drivers/cpufreq/exynos-cpufreq.c | 209 - drivers/cpufreq/exynos-cpufreq.h | 91 drivers/cpufreq/exynos4210-cpufreq.c | 157 --- drivers/cpufreq/exynos4x12-cpufreq.c | 211 - drivers/cpufreq/exynos5250-cpufreq.c | 183 include/dt-bindings/clock/exynos5250.h |1 + 34 files changed, 799 insertions(+), 936 deletions(-) create mode 100644 drivers/clk/samsung/clk-cpu.c delete mode 100644 drivers/cpufreq/exynos-cpufreq.c delete mode 100644 drivers/cpufreq/exynos-cpufreq.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 drivers/cpufreq/exynos4x12-cpufreq.c delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c -- 1.7.4.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
[PATCH v4 2/8] clk: samsung: change scope of samsung clock lock to global
From: Thomas Abraham thomas...@samsung.com
Access to samsung clock lock is required to support newer samsung specific
clock types. So change the scope of the samsung clock lock to global. And
prefix 'samsung_clk_' to the existing name of the lock to prevent name space
pollution.
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
drivers/clk/samsung/clk.c | 13 -
drivers/clk/samsung/clk.h |2 ++
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index 91bec3e..c86c28c 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -14,7 +14,7 @@
#include linux/syscore_ops.h
#include clk.h
-static DEFINE_SPINLOCK(lock);
+DEFINE_SPINLOCK(samsung_clk_lock);
static struct clk **clk_table;
static void __iomem *reg_base;
#ifdef CONFIG_OF
@@ -173,7 +173,8 @@ void __init samsung_clk_register_mux(struct
samsung_mux_clock *list,
for (idx = 0; idx nr_clk; idx++, list++) {
clk = clk_register_mux(NULL, list-name, list-parent_names,
list-num_parents, list-flags, reg_base + list-offset,
- list-shift, list-width, list-mux_flags, lock);
+ list-shift, list-width, list-mux_flags,
+ samsung_clk_lock);
if (IS_ERR(clk)) {
pr_err(%s: failed to register clock %s\n, __func__,
list-name);
@@ -206,12 +207,13 @@ void __init samsung_clk_register_div(struct
samsung_div_clock *list,
list-parent_name, list-flags,
reg_base + list-offset, list-shift,
list-width, list-div_flags,
- list-table, lock);
+ list-table, samsung_clk_lock);
else
clk = clk_register_divider(NULL, list-name,
list-parent_name, list-flags,
reg_base + list-offset, list-shift,
- list-width, list-div_flags, lock);
+ list-width, list-div_flags,
+ samsung_clk_lock);
if (IS_ERR(clk)) {
pr_err(%s: failed to register clock %s\n, __func__,
list-name);
@@ -241,7 +243,8 @@ void __init samsung_clk_register_gate(struct
samsung_gate_clock *list,
for (idx = 0; idx nr_clk; idx++, list++) {
clk = clk_register_gate(NULL, list-name, list-parent_name,
list-flags, reg_base + list-offset,
- list-bit_idx, list-gate_flags, lock);
+ list-bit_idx, list-gate_flags,
+ samsung_clk_lock);
if (IS_ERR(clk)) {
pr_err(%s: failed to register clock %s\n, __func__,
list-name);
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index c7141ba..951bc85 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -21,6 +21,8 @@
#include linux/of_address.h
#include clk-pll.h
+extern spinlock_t samsung_clk_lock;
+
/**
* struct samsung_clock_alias: information about mux clock
* @id: platform specific id of the clock.
--
1.7.4.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
[PATCH v4 1/8] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
From: Thomas Abraham thomas...@samsung.com
Lookup for the optional boost-frequency property in cpu0 node and if
available, enable support for boost mode frequencies. The frequencies
usable in boost mode are determined while preparing the cpufreq table
from the list of operating points available.
Cc: Shawn Guo shawn@linaro.org
Cc: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |2 ++
drivers/cpufreq/Kconfig| 11 +++
drivers/cpufreq/cpufreq-cpu0.c |5 +
3 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index f055515..60f321a 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -19,6 +19,8 @@ Optional properties:
- cooling-min-level:
- cooling-max-level:
Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
+- boost-frequency:
+ Please refer to
Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
Examples:
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 1fbe11f..0ca4485 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -194,6 +194,17 @@ config GENERIC_CPUFREQ_CPU0
If in doubt, say N.
+config GENERIC_CPUFREQ_CPU0_BOOST
+ bool Boost frequency support for generic CPU0 cpufreq driver
+ depends on GENERIC_CPUFREQ_CPU0
+ select CPU_FREQ_BOOST_SW
+ help
+ This enables support for software managed overclocking (BOOST). It
+ allows usage of special frequencies (those beyond the normal operating
+ frequencies).
+
+ If in doubt, say N.
+
menu x86 CPU frequency scaling drivers
depends on X86
source drivers/cpufreq/Kconfig.x86
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 1bf6bba..e6c21a8 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -194,6 +194,11 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
transition_latency += ret * 1000;
}
+#ifdef CONFIG_GENERIC_CPUFREQ_CPU0_BOOST
+ if (of_find_property(cpu_dev-of_node, boost-frequency, NULL))
+ cpu0_cpufreq_driver.boost_supported = true;
+#endif
+
ret = cpufreq_register_driver(cpu0_cpufreq_driver);
if (ret) {
pr_err(failed register driver: %d\n, ret);
--
1.7.4.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
[PATCH v4 4/8] Documentation: devicetree: add cpu clock configuration data binding for Exynos4/5
From; Thomas Abraham thomas...@samsung.com The clock blocks within the CMU_CPU clock domain are put together into a new composite clock type called the cpu clock. This clock type requires configuration data that will be atomically programmed in the multiple clock blocks encapsulated within the cpu clock type when the parent clock frequency is changed. This configuration data is held in the clock controller node. Update clock binding documentation about this configuration data format for Samsung Exynos4 and Exynos5 platforms. Cc: Tomasz Figa t.f...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org Signed-off-by: Thomas Abraham thomas...@samsung.com --- .../devicetree/bindings/clock/exynos4-clock.txt| 37 .../devicetree/bindings/clock/exynos5250-clock.txt | 36 +++ 2 files changed, 73 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt index f5a5b19..0934e02 100644 --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt @@ -15,6 +15,35 @@ Required Properties: - #clock-cells: should be 1. +- samsung,armclk-divider-table: when the frequency of the APLL is changed + the divider clocks in CMU_CPU clock domain also need to be updated. These + divider clocks have SoC specific divider clock output requirements for a + specific APLL clock speeds. When APLL clock rate is changed, these divider + clocks are reprogrammed with pre-determined values in order to maintain the + SoC specific divider clock outputs. This property lists the divider values + for divider clocks in the CMU_CPU block for supported APLL clock speeds. + The format of each entry included in the arm-frequency-table should be + as defined below + + - for Exynos4210 and Exynos4212 based platforms: + cell #1: arm clock parent frequency + cell #2 ~ cell 9#: value of clock divider in the following order + corem0_ratio, corem1_ratio, periph_ratio, atb_ratio, + pclk_dbg_ratio, apll_ratio, copy_ratio, hpm_ratio. + + - for Exynos4412 based platforms: + cell #1: expected arm clock parent frequency + cell #2 ~ cell #10: value of clock divider in the following order + corem0_ratio, corem1_ratio, periph_ratio, atb_ratio, + pclk_dbg_ratio, apll_ratio, copy_ratio, hpm_ratio, cores_ratio + +- samsung,armclk-cells: defines the number of cells in + samsung,armclk-divider-table property. The value of this property depends on + the SoC type. + + - for Exynos4210 and Exynos4212: the value should be 9. + - for Exynos4412: the value should be 10. + Each clock is assigned an identifier and client nodes can use this identifier to specify the clock which they consume. @@ -28,6 +57,14 @@ Example 1: An example of a clock controller node is listed below. compatible = samsung,exynos4210-clock; reg = 0x1003 0x2; #clock-cells = 1; + + samsung,armclk-cells = 9; + samsung,armclk-divider-table = 120 3 7 3 4 1 7 5 0, + 100 3 7 3 4 1 7 4 0, + 80 3 7 3 3 1 7 3 0, + 50 3 7 3 3 1 7 3 0, + 40 3 7 3 3 1 7 3 0, + 20 1 3 1 1 1 0 3 0; }; Example 2: UART controller node that consumes the clock generated by the clock diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt index 536eacd..3d63d09 100644 --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt @@ -13,6 +13,24 @@ Required Properties: - #clock-cells: should be 1. +- samsung,armclk-divider-table: when the frequency of the APLL is changed + the divider clocks in CMU_CPU clock domain also need to be updated. These + divider clocks have SoC specific divider clock output requirements for a + specific APLL clock speeds. When APLL clock rate is changed, these divider + clocks are reprogrammed with pre-determined values in order to maintain the + SoC specific divider clock outputs. This property lists the divider values + for divider clocks in the CMU_CPU block for supported APLL clock speeds. + The format of each entry included in the arm-frequency-table should be + as defined below + + cell #1: expected arm clock parent frequency + cell #2 ~ cell #9: value of clock divider in the following order +
[PATCH v4 3/8] clk: samsung: add infrastructure to register cpu clocks
From: Thomas Abraham thomas...@samsung.com
The CPU clock provider supplies the clock to the CPU clock domain. The
composition and organization of the CPU clock provider could vary among
Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
and gates. This patch defines a new clock type for CPU clock provider and
adds infrastructure to register the CPU clock providers for Samsung
platforms.
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
drivers/clk/samsung/Makefile |2 +-
drivers/clk/samsung/clk-cpu.c | 458 +
drivers/clk/samsung/clk.h |5 +
3 files changed, 464 insertions(+), 1 deletions(-)
create mode 100644 drivers/clk/samsung/clk-cpu.c
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..e2b453f 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -2,7 +2,7 @@
# Samsung Clock specific Makefile
#
-obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
+obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
new file mode 100644
index 000..6a40862
--- /dev/null
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -0,0 +1,458 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Thomas Abraham thomas...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This file contains the utility functions to register the cpu clocks
+ * for samsung platforms.
+*/
+
+#include linux/errno.h
+#include clk.h
+
+#define SRC_CPU0x0
+#define STAT_CPU 0x200
+#define DIV_CPU0 0x300
+#define DIV_CPU1 0x304
+#define DIV_STAT_CPU0 0x400
+#define DIV_STAT_CPU1 0x404
+
+#define MAX_DIV8
+
+#define EXYNOS4210_ARM_DIV1(div) ((div 0x7) + 1)
+#define EXYNOS4210_ARM_DIV2(div) (((div 28) 0x7) + 1)
+
+#define EXYNOS4210_DIV_CPU0(d5, d4, d3, d2, d1, d0)\
+ ((d5 24) | (d4 20) | (d3 16) | (d2 12) |\
+(d1 8) | (d0 4))
+#define EXYNOS4210_DIV_CPU1(d2, d1, d0)
\
+ ((d2 8) | (d1 4) | (d0 0))
+
+#define EXYNOS4210_DIV1_HPM_MASK ((0x7 0) | (0x7 4))
+#define EXYNOS4210_MUX_HPM_MASK(1 20)
+
+/**
+ * struct exynos4210_armclk_data: config data to setup exynos4210 cpu clocks.
+ * @prate: frequency of the parent clock.
+ * @div0: value to be programmed in the div_cpu0 register.
+ * @div1: value to be programmed in the div_cpu1 register.
+ *
+ * This structure holds the divider configuration data for divider clocks
+ * belonging to the CMU_CPU clock domain. The parent frequency at which these
+ * divider values are vaild is specified in @prate.
+ */
+struct exynos4210_armclk_data {
+ unsigned long prate;
+ unsigned intdiv0;
+ unsigned intdiv1;
+};
+
+/**
+ * struct exynos_cpuclk: information about clock supplied to a CPU core.
+ * @hw:handle between ccf and cpu clock.
+ * @alt_parent:alternate parent clock to use when switching the speed
+ * of the primary parent clock.
+ * @ctrl_base: base address of the clock controller.
+ * @offset:offset from the ctrl_base address where the cpu clock div/mux
+ * registers can be accessed.
+ * @clk_nb:clock notifier registered for changes in clock speed of the
+ * primary parent clock.
+ * @lock: register access lock.
+ * @data: optional data which the acutal instantiation of this clock
+ * can use.
+ */
+struct exynos_cpuclk {
+ struct clk_hw hw;
+ struct clk *alt_parent;
+ void __iomem*ctrl_base;
+ unsigned long offset;
+ struct notifier_block clk_nb;
+ spinlock_t *lock;
+ void*data;
+};
+
+#define to_exynos_cpuclk_hw(hw) container_of(hw, struct exynos_cpuclk, hw)
+#define to_exynos_cpuclk_nb(nb) container_of(nb, struct exynos_cpuclk, clk_nb)
+
+/**
+ * struct exynos_cpuclk_soc_data: soc specific data for cpu clocks.
+ * @parser:pointer to a function that can parse SoC specific data.
+ * @ops: clock operations to be used for this clock.
+ * @offset:optional offset from base of clock controller register base, to
+ * be used when accessing clock controller registers related to the
+ * cpu clock.
+ * @clk_cb:the clock notifier callback to be called for changes in the
+ * clock rate of the
[PATCH v4 6/8] ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data
From: Thomas Abraham thomas...@samsung.com
For all Exynos based platforms, add CPU nodes, operating points and cpu
clock data for migrating from Exynos specific cpufreq driver to using
generic cpufreq-cpu0 driver.
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
arch/arm/boot/dts/exynos4210-origen.dts |6 +++
arch/arm/boot/dts/exynos4210-trats.dts |6 +++
arch/arm/boot/dts/exynos4210-universal_c210.dts |6 +++
arch/arm/boot/dts/exynos4210.dtsi | 35 +++
arch/arm/boot/dts/exynos4212.dtsi | 18 ++
arch/arm/boot/dts/exynos4412-odroidx.dts|6 +++
arch/arm/boot/dts/exynos4412-origen.dts |6 +++
arch/arm/boot/dts/exynos4412-trats2.dts |6 +++
arch/arm/boot/dts/exynos4412.dtsi | 31 +
arch/arm/boot/dts/exynos4x12.dtsi | 36
arch/arm/boot/dts/exynos5250-arndale.dts|6 +++
arch/arm/boot/dts/exynos5250-cros-common.dtsi |6 +++
arch/arm/boot/dts/exynos5250-smdk5250.dts |6 +++
arch/arm/boot/dts/exynos5250.dtsi | 41 +++
14 files changed, 215 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 72fb11f..4324b25 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -32,6 +32,12 @@
bootargs =root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC2,115200 init=/linuxrc;
};
+ cpus {
+ cpu@0 {
+ cpu0-supply = buck1_reg;
+ };
+ };
+
regulators {
compatible = simple-bus;
#address-cells = 1;
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 63aa2bb..7cc0a57 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -30,6 +30,12 @@
bootargs = console=ttySAC2,115200N8 root=/dev/mmcblk0p5
rootwait earlyprintk panic=5;
};
+ cpus {
+ cpu: cpu@0 {
+ cpu0-supply = varm_breg;
+ };
+ };
+
regulators {
compatible = simple-bus;
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 63e34b2..844f3fb 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,12 @@
bootargs = console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait earlyprintk panic=5 maxcpus=1;
};
+ cpus {
+ cpu: cpu@0 {
+ cpu0-supply = vdd_arm_reg;
+ };
+ };
+
mct@1005 {
compatible = none;
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf614..22b967d 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -36,6 +36,33 @@
reg = 0x10023CA0 0x20;
};
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 0;
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+
+ operating-points =
+ 120 125
+ 100 115
+ 80 1075000
+ 50 975000
+ 40 975000
+ 20 95
+ ;
+ };
+
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 1;
+ };
+ };
+
gic: interrupt-controller@1049 {
cpu-offset = 0x8000;
};
@@ -73,6 +100,14 @@
compatible = samsung,exynos4210-clock;
reg = 0x1003 0x2;
#clock-cells = 1;
+
+ samsung,armclk-cells = 9;
+ samsung,armclk-divider-table = 120 3 7 3 4 1 7 5 0,
+ 100 3 7 3 4 1 7 4 0,
+ 80 3 7 3 3 1 7 3 0,
+ 50 3 7 3 3 1 7 3 0,
+ 40 3 7 3 3 1 7 3 0,
+ 20 1 3 1 1 1 0 3 0;
};
pmu {
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index
[PATCH v4 5/8] clk: exynos: use cpu-clock provider type to represent arm clock.
From: Thomas Abraham thomas...@samsung.com
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type and the independent
clock blocks that made up the arm clock can be removed.
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
drivers/clk/samsung/clk-exynos4.c | 25 +
drivers/clk/samsung/clk-exynos5250.c | 12 ++--
include/dt-bindings/clock/exynos5250.h |1 +
3 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index b4f9672..7e3bb16c 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -471,7 +471,6 @@ static struct samsung_mux_clock exynos4210_mux_clks[]
__initdata = {
MUX(0, mout_fimd1, group1_p4210, E4210_SRC_LCD1, 0, 4),
MUX(0, mout_mipi1, group1_p4210, E4210_SRC_LCD1, 12, 4),
MUX(CLK_SCLK_MPLL, sclk_mpll, mout_mpll_p, SRC_CPU, 8, 1),
- MUX(CLK_MOUT_CORE, mout_core, mout_core_p4210, SRC_CPU, 16, 1),
MUX(CLK_SCLK_VPLL, sclk_vpll, sclk_vpll_p4210, SRC_TOP0, 8, 1),
MUX(CLK_MOUT_FIMC0, mout_fimc0, group1_p4210, SRC_CAM, 0, 4),
MUX(CLK_MOUT_FIMC1, mout_fimc1, group1_p4210, SRC_CAM, 4, 4),
@@ -530,7 +529,6 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
__initdata = {
MUX(0, mout_jpeg, mout_jpeg_p, E4X12_SRC_CAM1, 8, 1),
MUX(CLK_SCLK_MPLL, sclk_mpll, mout_mpll_p, SRC_DMC, 12, 1),
MUX(CLK_SCLK_VPLL, sclk_vpll, mout_vpll_p, SRC_TOP0, 8, 1),
- MUX(CLK_MOUT_CORE, mout_core, mout_core_p4x12, SRC_CPU, 16, 1),
MUX(CLK_MOUT_FIMC0, mout_fimc0, group1_p4x12, SRC_CAM, 0, 4),
MUX(CLK_MOUT_FIMC1, mout_fimc1, group1_p4x12, SRC_CAM, 4, 4),
MUX(CLK_MOUT_FIMC2, mout_fimc2, group1_p4x12, SRC_CAM, 8, 4),
@@ -572,8 +570,6 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
__initdata = {
/* list of divider clocks supported in all exynos4 soc's */
static struct samsung_div_clock exynos4_div_clks[] __initdata = {
- DIV(0, div_core, mout_core, DIV_CPU0, 0, 3),
- DIV(0, div_core2, div_core, DIV_CPU0, 28, 3),
DIV(0, div_fimc0, mout_fimc0, DIV_CAM, 0, 4),
DIV(0, div_fimc1, mout_fimc1, DIV_CAM, 4, 4),
DIV(0, div_fimc2, mout_fimc2, DIV_CAM, 8, 4),
@@ -619,8 +615,8 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
DIV(0, div_spi_pre2, div_spi2, DIV_PERIL2, 8, 8),
DIV(0, div_audio1, mout_audio1, DIV_PERIL4, 0, 4),
DIV(0, div_audio2, mout_audio2, DIV_PERIL4, 16, 4),
- DIV(CLK_ARM_CLK, arm_clk, div_core2, DIV_CPU0, 28, 3),
- DIV(CLK_SCLK_APLL, sclk_apll, mout_apll, DIV_CPU0, 24, 3),
+ DIV_F(CLK_SCLK_APLL, sclk_apll, mout_apll, DIV_CPU0, 24, 3,
+ CLK_GET_RATE_NOCACHE, 0),
DIV_F(0, div_mipi_pre0, div_mipi0, DIV_LCD0, 20, 4,
CLK_SET_RATE_PARENT, 0),
DIV_F(0, div_mmc_pre0, div_mmc0, DIV_FSYS1, 8, 8,
@@ -1003,12 +999,6 @@ static struct samsung_gate_clock exynos4x12_gate_clks[]
__initdata = {
0),
};
-static struct samsung_clock_alias exynos4_aliases[] __initdata = {
- ALIAS(CLK_MOUT_CORE, NULL, moutcore),
- ALIAS(CLK_ARM_CLK, NULL, armclk),
- ALIAS(CLK_SCLK_APLL, NULL, mout_apll),
-};
-
static struct samsung_clock_alias exynos4210_aliases[] __initdata = {
ALIAS(CLK_SCLK_MPLL, NULL, mout_mpll),
};
@@ -1241,6 +1231,9 @@ static void __init exynos4_clk_init(struct device_node
*np,
ARRAY_SIZE(exynos4210_gate_clks));
samsung_clk_register_alias(exynos4210_aliases,
ARRAY_SIZE(exynos4210_aliases));
+ exynos_register_arm_clock(CLK_ARM_CLK, mout_core_p4210,
+ ARRAY_SIZE(mout_core_p4210), reg_base, np, NULL,
+ samsung_clk_lock);
} else {
samsung_clk_register_mux(exynos4x12_mux_clks,
ARRAY_SIZE(exynos4x12_mux_clks));
@@ -1250,11 +1243,11 @@ static void __init exynos4_clk_init(struct device_node
*np,
ARRAY_SIZE(exynos4x12_gate_clks));
samsung_clk_register_alias(exynos4x12_aliases,
ARRAY_SIZE(exynos4x12_aliases));
+ exynos_register_arm_clock(CLK_ARM_CLK, mout_core_p4x12,
+ ARRAY_SIZE(mout_core_p4x12), reg_base, np, NULL,
+ samsung_clk_lock);
}
- samsung_clk_register_alias(exynos4_aliases,
- ARRAY_SIZE(exynos4_aliases));
-
exynos4_clk_sleep_init();
pr_info(%s clocks: sclk_apll = %ld, sclk_mpll = %ld\n
@@ -1262,7 +1255,7 @@ static void __init exynos4_clk_init(struct device_node
*np,
exynos4_soc == EXYNOS4210 ? Exynos4210 : Exynos4x12,
_get_rate(sclk_apll), _get_rate(sclk_mpll),
[PATCH v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
From: Thomas Abraham thomas...@samsung.com
Remove the platform device instantiation for Exynos specific cpufreq
driver and add the platform device for cpufreq-cpu0 driver.
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
arch/arm/mach-exynos/exynos.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907..489a495 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -232,7 +232,9 @@ void __init exynos_cpuidle_init(void)
void __init exynos_cpufreq_init(void)
{
- platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
+ if (!(of_machine_is_compatible(samsung,exynos5420))
+ !(of_machine_is_compatible(samsung,exynos5440)))
+ platform_device_register_simple(cpufreq-cpu0, -1, NULL, 0);
}
void __init exynos_init_late(void)
--
1.7.4.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
[PATCH v4 8/8] cpufreq: exynos: remove all exynos specific cpufreq driver support
From: Thomas Abraham thomas...@samsung.com Exynos4210, Exynos4x12 and Exynos5250 based platforms have switched over to use cpufreq-cpu0 driver for cpufreq functionality. So the Exynos specific cpufreq drivers for these platforms can be removed. Signed-off-by: Thomas Abraham thomas...@samsung.com --- drivers/cpufreq/Kconfig.arm | 52 - drivers/cpufreq/Makefile |4 - drivers/cpufreq/exynos-cpufreq.c | 209 - drivers/cpufreq/exynos-cpufreq.h | 91 --- drivers/cpufreq/exynos4210-cpufreq.c | 157 - drivers/cpufreq/exynos4x12-cpufreq.c | 211 -- drivers/cpufreq/exynos5250-cpufreq.c | 183 - 7 files changed, 0 insertions(+), 907 deletions(-) delete mode 100644 drivers/cpufreq/exynos-cpufreq.c delete mode 100644 drivers/cpufreq/exynos-cpufreq.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 drivers/cpufreq/exynos4x12-cpufreq.c delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 5805035..9721674 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -24,43 +24,6 @@ config ARM_VEXPRESS_SPC_CPUFREQ This add the CPUfreq driver support for Versatile Express big.LITTLE platforms using SPC for power management. - -config ARM_EXYNOS_CPUFREQ - bool - -config ARM_EXYNOS4210_CPUFREQ - bool SAMSUNG EXYNOS4210 - depends on CPU_EXYNOS4210 !ARCH_MULTIPLATFORM - default y - select ARM_EXYNOS_CPUFREQ - help - This adds the CPUFreq driver for Samsung EXYNOS4210 - SoC (S5PV310 or S5PC210). - - If in doubt, say N. - -config ARM_EXYNOS4X12_CPUFREQ - bool SAMSUNG EXYNOS4x12 - depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412) !ARCH_MULTIPLATFORM - default y - select ARM_EXYNOS_CPUFREQ - help - This adds the CPUFreq driver for Samsung EXYNOS4X12 - SoC (EXYNOS4212 or EXYNOS4412). - - If in doubt, say N. - -config ARM_EXYNOS5250_CPUFREQ - bool SAMSUNG EXYNOS5250 - depends on SOC_EXYNOS5250 !ARCH_MULTIPLATFORM - default y - select ARM_EXYNOS_CPUFREQ - help - This adds the CPUFreq driver for Samsung EXYNOS5250 - SoC. - - If in doubt, say N. - config ARM_EXYNOS5440_CPUFREQ bool SAMSUNG EXYNOS5440 depends on SOC_EXYNOS5440 @@ -75,21 +38,6 @@ config ARM_EXYNOS5440_CPUFREQ If in doubt, say N. -config ARM_EXYNOS_CPU_FREQ_BOOST_SW - bool EXYNOS Frequency Overclocking - Software - depends on ARM_EXYNOS_CPUFREQ - select CPU_FREQ_BOOST_SW - select EXYNOS_THERMAL - help - This driver supports software managed overclocking (BOOST). - It allows usage of special frequencies for Samsung Exynos - processors if thermal conditions are appropriate. - - It reguires, for safe operation, thermal framework with properly - defined trip points. - - If in doubt, say N. - config ARM_HIGHBANK_CPUFREQ tristate Calxeda Highbank-based depends on ARCH_HIGHBANK GENERIC_CPUFREQ_CPU0 REGULATOR diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index 738c8b7..8a75419 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -51,10 +51,6 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o obj-$(CONFIG_ARCH_DAVINCI_DA850) += davinci-cpufreq.o obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o -obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c deleted file mode 100644 index f99cfe2..000 --- a/drivers/cpufreq/exynos-cpufreq.c +++ /dev/null @@ -1,209 +0,0 @@ -/* - * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd. - * http://www.samsung.com - * - * EXYNOS - CPU frequency scaling support for EXYNOS series - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. -*/ - -#include linux/kernel.h -#include linux/err.h -#include linux/clk.h -#include linux/io.h -#include linux/slab.h -#include linux/regulator/consumer.h -#include linux/cpufreq.h -#include linux/platform_device.h - -#include plat/cpu.h - -#include exynos-cpufreq.h - -static struct exynos_dvfs_info *exynos_info;
Re: [PATCH v3 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
On Tue, May 13, 2014 at 8:03 PM, Thomas Abraham ta.oma...@gmail.com wrote: From: Thomas Abraham thomas...@samsung.com Add a new optional boost-frequency binding for specifying the frequencies usable in boost mode. Cc: Nishanth Menon n...@ti.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Signed-off-by: Thomas Abraham thomas...@samsung.com --- .../devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt new file mode 100644 index 000..d925e38 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt @@ -0,0 +1,11 @@ +* Device tree binding for CPU boost frequency (aka over-clocking) + +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as +overclocking) in which the CPU can operate in frequencies beyond the normal operate at? +operating conditions. normal operating conditions probably need a little bit of an expansion here perhaps? + +Optional Properties: +- boost-frequency: list of frequencies in KHz to be used only in boost mode. probably boost-frequencies? + This list should be a subset of frequencies listed in operating-points + property. Refer to Documentation/devicetree/bindings/power/opp.txt for + details about operating-points property. an example is expected here. personally, I think I understand the intent here, but as a hardware description, will let folks comment if it is acceptable. -- Regards, Nishanth Menon -- 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 5/5] arm: exynos: Add MCPM call-back functions
Hi Lorenzo,
On Tue, May 13, 2014 at 10:18 PM, Lorenzo Pieralisi
lorenzo.pieral...@arm.com wrote:
On Tue, May 13, 2014 at 12:58:44PM +0100, Abhilash Kesavan wrote:
[...]
+static int __init exynos_mcpm_init(void)
+{
+ struct device_node *node;
+ int ret = 0;
There is no point in initializing it to 0.
OK.
+
+ node = of_find_compatible_node(NULL, NULL, samsung,exynos5420);
+ if (!node)
+ return -ENODEV;
+ of_node_put(node);
+
+ if (!cci_probed())
+ return -ENODEV;
+
+ node = of_find_compatible_node(NULL, NULL,
+ samsung,exynos4210-sysram-ns);
+ if (!node)
+ return -ENODEV;
+
+ ns_sram_base_addr = of_iomap(node, 0);
+ of_node_put(node);
+ if (!ns_sram_base_addr) {
+ pr_err(failed to map non-secure iRAM base address\n);
+ return -ENOMEM;
+ }
+
+ /*
+* To increase the stability of KFC reset we need to program
+* the PMU SPARE3 register
+*/
+ __raw_writel(EXYNOS5420_SWRESET_KFC_SEL, S5P_PMU_SPARE3);
+
+ exynos_mcpm_usage_count_init();
+
+ ret = mcpm_platform_register(exynos_power_ops);
+ if (!ret)
+ ret = mcpm_sync_init(exynos_pm_power_up_setup);
+ if (ret) {
+ iounmap(ns_sram_base_addr);
+ return ret;
+ }
+
+ mcpm_smp_set_ops();
+
+ pr_info(Exynos MCPM support installed\n);
+
+ /*
+* Future entries into the kernel can now go
+* through the cluster entry vectors.
+*/
+ __raw_writel(virt_to_phys(mcpm_entry_point),
+ ns_sram_base_addr + MCPM_BOOT_ADDR_OFFSET);
+
ns_sram_base_addr must be unmapped, since it is unused after the write.
Will unmap.
Regards,
Abhilash
--
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 3/5] ARM: dts: enable hdmi for exynos5420 based peach-pit board
From: Rahul Sharma rahul.sha...@samsung.com
Enable hdmi for exynos5420 based peach-pit board.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 19 +++
arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 +++
arch/arm/boot/dts/exynos5420.dtsi |5 +
3 files changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index fae33dd..8248255 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -137,6 +137,25 @@
};
};
+i2c_2 {
+ status = okay;
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 66000;
+ samsung,i2c-slave-addr = 0x50;
+
+ hdmiddc@50 {
+ reg = 0x50;
+ };
+};
+
+hdmi {
+ status = okay;
+ hpd-gpio = gpx3 7 2;
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_hpd_irq;
+ ddc = i2c_2;
+};
+
/*
* Use longest HW watchdog in SoC (32 seconds) since the hardware
* watchdog provides no debugging information (compared to soft/hard
diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
index ba686e4..fc17797 100644
--- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
@@ -66,6 +66,13 @@
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
+
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = gpx3-7;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
};
pinctrl@1341 {
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 016992c..df4422c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -648,9 +648,14 @@
clock CLK_MOUT_HDMI;
clock-names = hdmi, sclk_hdmi, sclk_pixel,
sclk_hdmiphy, mout_hdmi;
+ phy = hdmiphy;
status = disabled;
};
+ hdmiphy: hdmiphy@145D {
+ reg = 0x145D 0x20;
+ };
+
mixer: mixer@1445 {
compatible = samsung,exynos5420-mixer;
reg = 0x1445 0x1;
--
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 v4 2/5] ARM: dts: change to correct compatible string for exynos5420 hdmi
From: Rahul Sharma rahul.sha...@samsung.com
Replace compatible string for HDMI node in Exynos5420. Since
latest restructring in Drm hdmi driver, it is agreed to use
a seperate compatible string for Exynos5420 HDMI IP siince it
uses APB mapped Phy.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index a802f74..016992c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -640,7 +640,7 @@
};
hdmi: hdmi@1453 {
- compatible = samsung,exynos4212-hdmi;
+ compatible = samsung,exynos5420-hdmi;
reg = 0x1453 0x7;
interrupts = 0 95 0;
clocks = clock CLK_HDMI, clock CLK_SCLK_HDMI,
--
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 v4 1/5] ARM: dts: enable hdmi for exynos5250 based snow board
From: Rahul Sharma rahul.sha...@samsung.com
Enable support for HDMI for exynos5250 based Snow board.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5250-cros-common.dtsi |6 +-
arch/arm/boot/dts/exynos5250-pinctrl.dtsi |7 +++
arch/arm/boot/dts/exynos5250-snow.dts |7 +++
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
index 2c1560d..89ac90f 100644
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
@@ -240,7 +240,7 @@
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 378000;
- hdmiphy@38 {
+ hdmiphy: hdmiphy@38 {
compatible = samsung,exynos4212-hdmiphy;
reg = 0x38;
};
@@ -304,6 +304,10 @@
hdmi {
hpd-gpio = gpx3 7 0;
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_hpd_irq;
+ phy = hdmiphy;
+ ddc = i2c_2;
};
gpio-keys {
diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
index 9a49e68..da3ae66 100644
--- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
@@ -560,6 +560,13 @@
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
+
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = gpx3-7;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
};
pinctrl@1340 {
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1ce1088..696850a 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -206,4 +206,11 @@
clock-frequency = 2400;
};
};
+
+ hdmi {
+ hdmi-en-supply = tps65090_fet7;
+ vdd-supply = ldo8_reg;
+ vdd_osc-supply = ldo10_reg;
+ vdd_pll-supply = ldo8_reg;
+ };
};
--
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 v4 5/5] ARM: dts: enable hdmi for exynos5800 based peach-pi board
From: Rahul Sharma rahul.sha...@samsung.com
Enable hdmi for peach-pi board.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 742655b..2a6f23b8 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -134,6 +134,25 @@
};
};
+i2c_2 {
+ status = okay;
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 66000;
+ samsung,i2c-slave-addr = 0x50;
+
+ hdmiddc@50 {
+ reg = 0x50;
+ };
+};
+
+hdmi {
+ status = okay;
+ hpd-gpio = gpx3 7 2;
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_hpd_irq;
+ ddc = i2c_2;
+};
+
/*
* Use longest HW watchdog in SoC (32 seconds) since the hardware
* watchdog provides no debugging information (compared to soft/hard
--
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 v4 0/5] ARM: dts: enable hdmi for exynos5 based peach and snow boards
From: Rahul Sharma rahul.sha...@samsung.com Enable hdmi for exynos5250 based snow board, exynos5420 based peach pit board and 5800 based peach-pi board. V4: 1) Removed hdmi_hpd_irq pin from peach-pi board as it already present in exynos5420-pinctrl.dtsi. V3: 1) Re-spin on dependent patches. 2) Added patch to enable hdmi for Peach-pi board. V2: 1) Re-spin on dependent patches. 2) Added patch to remove chip specific hdmi hpd gpio from board file top SoC file. This series is based on Kukjin Kims, for-next branch. It is dependent on 1) Sachin's patch: ARM: dts: exynos5250-snow: add tps65090 power regulator at https://patches.linaro.org/28325/ : [Reviewed-by: Doug Anderson] All other dependent patches are already landed in maintainers tree. Rahul Sharma (5): ARM: dts: enable hdmi for exynos5250 based snow board ARM: dts: change to correct compatible string for exynos5420 hdmi ARM: dts: enable hdmi for exynos5420 based peach-pit board ARM: dts: remove chip specific hdmi hpd pin from board ARM: dts: enable hdmi for exynos5800 based peach-pi board arch/arm/boot/dts/exynos5250-cros-common.dtsi |6 +- arch/arm/boot/dts/exynos5250-pinctrl.dtsi |7 +++ arch/arm/boot/dts/exynos5250-snow.dts |7 +++ arch/arm/boot/dts/exynos5420-peach-pit.dts| 19 +++ arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 +++ arch/arm/boot/dts/exynos5420-smdk5420.dts |9 - arch/arm/boot/dts/exynos5420.dtsi |7 ++- arch/arm/boot/dts/exynos5800-peach-pi.dts | 19 +++ 8 files changed, 70 insertions(+), 11 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 v4 4/5] ARM: dts: remove chip specific hdmi hpd pin from board
From: Rahul Sharma rahul.sha...@samsung.com
gpx3-7 is chip specific pin in Exynos5420 for hdmi
hotplug. This pin is moved to exynos5420-pinctrl.dts
and removed from the board file.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5420-smdk5420.dts |9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 6910485..11cd9bf 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -131,15 +131,6 @@
};
};
- pinctrl@1340 {
- hdmi_hpd_irq: hdmi-hpd-irq {
- samsung,pins = gpx3-7;
- samsung,pin-function = 0;
- samsung,pin-pud = 1;
- samsung,pin-drv = 0;
- };
- };
-
hdmi@1453 {
status = okay;
hpd-gpio = gpx3 7 0;
--
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 v4 5/5] mcpm: exynos: populate suspend and powered_up callbacks
Hi Lorenzo,
On 13 May 2014 22:44, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote:
On Tue, May 13, 2014 at 12:43:31PM +0100, Chander Kashyap wrote:
[...]
+static void exynos_suspend(u64 residency)
+{
+ unsigned int mpidr, cpunr;
+
+ mpidr = read_cpuid_mpidr();
+ cpunr = exynos_pmu_cpunr(mpidr);
If I were to be picky, I would compute these values only if they
are needed, ie move the computation after exynos_power_down().
Yes thats make sense. I will realign it.
There is another quite horrible issue here. We know this code works
because the processors A15/A7 hit the caches with C bit in SCTLR cleared.
On processors where this is not true, this sequence would explode
if power down fails (in case core is gated but L2 is still powered on,
the stack is stuck in L2) since it is going to read stack data that is
in L2 but can't be read.
It is not related to this sequence only, but it is an issue in general
and wanted to mention that on the lists for public awareness.
Can you please elaborate. I didn't understand.
It is not related to this patch only. This function carries out writes to the
stack (which might end up in eg L2) and then disables the C bit in SCTLR
through MCPM.
A15 and A7 processors hit the cache with the C bit clear in the SCTLR
so the processor still hits the stack values if the power down fails.
On processors where caches are not hit with the C bit clear (eg A9) this code
would fail since the stack values that sit in the caches cannot be read with
the C bit clear in SCTLR until the SCTLR is restored, so it will have to
be implemented in assembly with no stack usage (or better, no cacheable data
usage).
So, all I am saying is, to avoid copy'n'paste havoc and to avoid running
this code on Exynos platforms where it must not be run as-is, please add
a comment along the line:
This function requires the stack data to be visible through power down
and can only be executed on processors like A15 and A7 that hit the cache
with the C bit clear in the SCTLR register.
Please let me know if that's clear.
It all clear now.
Thanks a lot.
Lorenzo
The gist of what I am saying is, please add a comment to that extent,
here and it should be added in exynos_power_down() too.
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr +
0x1c);
No magic numbers please (0x1c). You can add a macro/wrapper, as TC2 does.
Yes i will remove it.
+ exynos_power_down();
+
+ /*
+ * Execution reaches here only if cpu did not power down.
+ * Hence roll back the changes done in exynos_power_down function.
+ */
+ exynos_cpu_powerup(cpunr);
Please be aware that if this function returns MCPM will soft reboot, and
the CPUidle driver will have no way to detect a state entry failure.
I am just flagging this up, since fixing this behaviour is not easy, and
honestly, since power down failure should be the exception not the rule,
the idle stats should not be affected much.
I think this is the proper way of implementing the sequence but please
all keep in mind what I wrote above.
Lorenzo
+}
+
static const struct mcpm_platform_ops exynos_power_ops = {
.power_up = exynos_power_up,
.power_down = exynos_power_down,
.power_down_finish = exynos_power_down_finish,
+ .suspend= exynos_suspend,
+ .powered_up = exynos_powered_up,
};
static void __init exynos_mcpm_usage_count_init(void)
--
1.7.9.5
--
with warm regards,
Chander Kashyap
--
with warm regards,
Chander Kashyap
--
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 5/5] arm: exynos: Add MCPM call-back functions
On 14 May 2014 08:14, Abhilash Kesavan kesavan.abhil...@gmail.com wrote:
Hi Lorenzo,
On Tue, May 13, 2014 at 10:18 PM, Lorenzo Pieralisi
lorenzo.pieral...@arm.com wrote:
On Tue, May 13, 2014 at 12:58:44PM +0100, Abhilash Kesavan wrote:
[...]
+static int __init exynos_mcpm_init(void)
+{
+ struct device_node *node;
+ int ret = 0;
There is no point in initializing it to 0.
OK.
+
+ node = of_find_compatible_node(NULL, NULL, samsung,exynos5420);
+ if (!node)
+ return -ENODEV;
+ of_node_put(node);
+
+ if (!cci_probed())
+ return -ENODEV;
+
+ node = of_find_compatible_node(NULL, NULL,
+ samsung,exynos4210-sysram-ns);
+ if (!node)
+ return -ENODEV;
+
+ ns_sram_base_addr = of_iomap(node, 0);
+ of_node_put(node);
+ if (!ns_sram_base_addr) {
+ pr_err(failed to map non-secure iRAM base address\n);
+ return -ENOMEM;
+ }
+
+ /*
+* To increase the stability of KFC reset we need to program
+* the PMU SPARE3 register
+*/
+ __raw_writel(EXYNOS5420_SWRESET_KFC_SEL, S5P_PMU_SPARE3);
+
+ exynos_mcpm_usage_count_init();
+
+ ret = mcpm_platform_register(exynos_power_ops);
+ if (!ret)
+ ret = mcpm_sync_init(exynos_pm_power_up_setup);
+ if (ret) {
+ iounmap(ns_sram_base_addr);
+ return ret;
+ }
+
+ mcpm_smp_set_ops();
+
+ pr_info(Exynos MCPM support installed\n);
+
+ /*
+* Future entries into the kernel can now go
+* through the cluster entry vectors.
+*/
+ __raw_writel(virt_to_phys(mcpm_entry_point),
+ ns_sram_base_addr + MCPM_BOOT_ADDR_OFFSET);
+
ns_sram_base_addr must be unmapped, since it is unused after the write.
Will unmap.
This mapping is required in for cpuilde (suspend) to program
mcpm_entry before going to suspend.
Regards,
Abhilash
--
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
--
with warm regards,
Chander Kashyap
--
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 5/5] arm: exynos: Add MCPM call-back functions
Hi Chander,
On Wed, May 14, 2014 at 8:24 AM, Chander Kashyap
chander.kash...@linaro.org wrote:
On 14 May 2014 08:14, Abhilash Kesavan kesavan.abhil...@gmail.com wrote:
Hi Lorenzo,
On Tue, May 13, 2014 at 10:18 PM, Lorenzo Pieralisi
lorenzo.pieral...@arm.com wrote:
On Tue, May 13, 2014 at 12:58:44PM +0100, Abhilash Kesavan wrote:
[...]
+static int __init exynos_mcpm_init(void)
+{
+ struct device_node *node;
+ int ret = 0;
There is no point in initializing it to 0.
OK.
+
+ node = of_find_compatible_node(NULL, NULL, samsung,exynos5420);
+ if (!node)
+ return -ENODEV;
+ of_node_put(node);
+
+ if (!cci_probed())
+ return -ENODEV;
+
+ node = of_find_compatible_node(NULL, NULL,
+ samsung,exynos4210-sysram-ns);
+ if (!node)
+ return -ENODEV;
+
+ ns_sram_base_addr = of_iomap(node, 0);
+ of_node_put(node);
+ if (!ns_sram_base_addr) {
+ pr_err(failed to map non-secure iRAM base address\n);
+ return -ENOMEM;
+ }
+
+ /*
+* To increase the stability of KFC reset we need to program
+* the PMU SPARE3 register
+*/
+ __raw_writel(EXYNOS5420_SWRESET_KFC_SEL, S5P_PMU_SPARE3);
+
+ exynos_mcpm_usage_count_init();
+
+ ret = mcpm_platform_register(exynos_power_ops);
+ if (!ret)
+ ret = mcpm_sync_init(exynos_pm_power_up_setup);
+ if (ret) {
+ iounmap(ns_sram_base_addr);
+ return ret;
+ }
+
+ mcpm_smp_set_ops();
+
+ pr_info(Exynos MCPM support installed\n);
+
+ /*
+* Future entries into the kernel can now go
+* through the cluster entry vectors.
+*/
+ __raw_writel(virt_to_phys(mcpm_entry_point),
+ ns_sram_base_addr + MCPM_BOOT_ADDR_OFFSET);
+
ns_sram_base_addr must be unmapped, since it is unused after the write.
Will unmap.
This mapping is required in for cpuilde (suspend) to program
mcpm_entry before going to suspend.
I forgot about your cpuidle patches. I need to retain the mapping then.
Abhilash
Regards,
Abhilash
--
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
--
with warm regards,
Chander Kashyap
--
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 5/5] arm: exynos: Add MCPM call-back functions
On Wed, 14 May 2014, Chander Kashyap wrote:
On 14 May 2014 08:14, Abhilash Kesavan kesavan.abhil...@gmail.com wrote:
Hi Lorenzo,
On Tue, May 13, 2014 at 10:18 PM, Lorenzo Pieralisi
lorenzo.pieral...@arm.com wrote:
On Tue, May 13, 2014 at 12:58:44PM +0100, Abhilash Kesavan wrote:
[...]
+static int __init exynos_mcpm_init(void)
+{
+ struct device_node *node;
+ int ret = 0;
There is no point in initializing it to 0.
OK.
+
+ node = of_find_compatible_node(NULL, NULL, samsung,exynos5420);
+ if (!node)
+ return -ENODEV;
+ of_node_put(node);
+
+ if (!cci_probed())
+ return -ENODEV;
+
+ node = of_find_compatible_node(NULL, NULL,
+ samsung,exynos4210-sysram-ns);
+ if (!node)
+ return -ENODEV;
+
+ ns_sram_base_addr = of_iomap(node, 0);
+ of_node_put(node);
+ if (!ns_sram_base_addr) {
+ pr_err(failed to map non-secure iRAM base address\n);
+ return -ENOMEM;
+ }
+
+ /*
+* To increase the stability of KFC reset we need to program
+* the PMU SPARE3 register
+*/
+ __raw_writel(EXYNOS5420_SWRESET_KFC_SEL, S5P_PMU_SPARE3);
+
+ exynos_mcpm_usage_count_init();
+
+ ret = mcpm_platform_register(exynos_power_ops);
+ if (!ret)
+ ret = mcpm_sync_init(exynos_pm_power_up_setup);
+ if (ret) {
+ iounmap(ns_sram_base_addr);
+ return ret;
+ }
+
+ mcpm_smp_set_ops();
+
+ pr_info(Exynos MCPM support installed\n);
+
+ /*
+* Future entries into the kernel can now go
+* through the cluster entry vectors.
+*/
+ __raw_writel(virt_to_phys(mcpm_entry_point),
+ ns_sram_base_addr + MCPM_BOOT_ADDR_OFFSET);
+
ns_sram_base_addr must be unmapped, since it is unused after the write.
Will unmap.
This mapping is required in for cpuilde (suspend) to program
mcpm_entry before going to suspend.
Why?
Nicolas
--
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] ARM: EXYNOS: Map SYSRAM through generic SRAM bindings
On 05/13/2014 03:37 PM, Paul Bolle wrote: Kukjin, On Tue, 2014-05-13 at 12:12 +0900, Kukjin Kim wrote: Tomasz Figa wrote: You mean s/sram/sysram/ in compatible strings of Exynos-specific reserved areas? If yes, I'm fine, it might be even better. Just remember to update documentation in patch 2/2 as well. Done. If any problems in my tree, please let me know. It seems this one just hit linux-next (in next-20140513) as ARM: EXYNOS: Map SYSRAM through generic DT bindings. Its commit now contains this hunk: --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -843,6 +843,7 @@ config ARCH_EXYNOS select HAVE_S3C_RTC if RTC_CLASS select NEED_MACH_MEMORY_H select SPARSE_IRQ + select SYSRAM select USE_OF help Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5) But there's no Kconfig symbol SYSRAM. However, there is a Kconfig symbol SRAM. Did you perhaps do one s/sram/sysram/ too many on the original patch? Also the compatible string name should be 'mmio-sram' on the DTS files. Paul Bolle -- 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 -- Tushar Behera -- 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 5/5] arm: exynos: Add MCPM call-back functions
On 14 May 2014 08:32, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Wed, 14 May 2014, Chander Kashyap wrote:
On 14 May 2014 08:14, Abhilash Kesavan kesavan.abhil...@gmail.com wrote:
Hi Lorenzo,
On Tue, May 13, 2014 at 10:18 PM, Lorenzo Pieralisi
lorenzo.pieral...@arm.com wrote:
On Tue, May 13, 2014 at 12:58:44PM +0100, Abhilash Kesavan wrote:
[...]
+static int __init exynos_mcpm_init(void)
+{
+ struct device_node *node;
+ int ret = 0;
There is no point in initializing it to 0.
OK.
+
+ node = of_find_compatible_node(NULL, NULL, samsung,exynos5420);
+ if (!node)
+ return -ENODEV;
+ of_node_put(node);
+
+ if (!cci_probed())
+ return -ENODEV;
+
+ node = of_find_compatible_node(NULL, NULL,
+ samsung,exynos4210-sysram-ns);
+ if (!node)
+ return -ENODEV;
+
+ ns_sram_base_addr = of_iomap(node, 0);
+ of_node_put(node);
+ if (!ns_sram_base_addr) {
+ pr_err(failed to map non-secure iRAM base address\n);
+ return -ENOMEM;
+ }
+
+ /*
+* To increase the stability of KFC reset we need to program
+* the PMU SPARE3 register
+*/
+ __raw_writel(EXYNOS5420_SWRESET_KFC_SEL, S5P_PMU_SPARE3);
+
+ exynos_mcpm_usage_count_init();
+
+ ret = mcpm_platform_register(exynos_power_ops);
+ if (!ret)
+ ret = mcpm_sync_init(exynos_pm_power_up_setup);
+ if (ret) {
+ iounmap(ns_sram_base_addr);
+ return ret;
+ }
+
+ mcpm_smp_set_ops();
+
+ pr_info(Exynos MCPM support installed\n);
+
+ /*
+* Future entries into the kernel can now go
+* through the cluster entry vectors.
+*/
+ __raw_writel(virt_to_phys(mcpm_entry_point),
+ ns_sram_base_addr + MCPM_BOOT_ADDR_OFFSET);
+
ns_sram_base_addr must be unmapped, since it is unused after the write.
Will unmap.
This mapping is required in for cpuilde (suspend) to program
mcpm_entry before going to suspend.
Why?
This is required to program the mcpm_entry point address (resume
address) after cpuidle exit/fail.
Abhilash, as i am not clearing it, it can be unmapped.
Thanks Nicolas.
Nicolas
--
with warm regards,
Chander Kashyap
--
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] ASoC: samsung: Add missing pm ops for Snow sound card driver
Adding missing pm ops so that audio playback works across
suspend and resume cycle.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
sound/soc/samsung/snow.c |1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/samsung/snow.c b/sound/soc/samsung/snow.c
index 0fa89a4..014c177 100644
--- a/sound/soc/samsung/snow.c
+++ b/sound/soc/samsung/snow.c
@@ -111,6 +111,7 @@ static struct platform_driver snow_driver = {
.driver = {
.name = snow-audio,
.owner = THIS_MODULE,
+ .pm = snd_soc_pm_ops,
.of_match_table = snow_of_match,
},
.probe = snow_probe,
--
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 v6 5/5] arm: exynos: Add MCPM call-back functions
On Wed, 14 May 2014, Chander Kashyap wrote: On 14 May 2014 08:32, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Wed, 14 May 2014, Chander Kashyap wrote: On 14 May 2014 08:14, Abhilash Kesavan kesavan.abhil...@gmail.com wrote: On Tue, May 13, 2014 at 10:18 PM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: On Tue, May 13, 2014 at 12:58:44PM +0100, Abhilash Kesavan wrote: + /* +* Future entries into the kernel can now go +* through the cluster entry vectors. +*/ + __raw_writel(virt_to_phys(mcpm_entry_point), + ns_sram_base_addr + MCPM_BOOT_ADDR_OFFSET); + ns_sram_base_addr must be unmapped, since it is unused after the write. Will unmap. This mapping is required in for cpuilde (suspend) to program mcpm_entry before going to suspend. Why? This is required to program the mcpm_entry point address (resume address) after cpuidle exit/fail. You should be using mcpm_set_entry_vector() for that. Once mcpm_entry_point is set, it shouldn't need to be changed. Nicolas -- 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] cpufreq / OPP: Allow boost frequency to be looked up from device tree
On 14 May 2014 06:32, Thomas Abraham ta.oma...@gmail.com wrote:
From: Thomas Abraham thomas...@samsung.com
Commit 6f19efc0 (cpufreq: Add boost frequency support in core) adds
support for CPU boost mode. This patch adds support for finding available
boost frequencies from device tree and marking them as usable in boost mode.
Cc: Nishanth Menon n...@ti.com
Cc: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
drivers/cpufreq/cpufreq_opp.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
index c0c6f4a..e3c97f3 100644
--- a/drivers/cpufreq/cpufreq_opp.c
+++ b/drivers/cpufreq/cpufreq_opp.c
@@ -19,6 +19,7 @@
#include linux/pm_opp.h
#include linux/rcupdate.h
#include linux/slab.h
+#include linux/of.h
/**
* dev_pm_opp_init_cpufreq_table() - create a cpufreq table for a device
@@ -51,6 +52,10 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table *freq_table = NULL;
int i, max_opps, ret = 0;
unsigned long rate;
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ int j, len;
+ u32 *boost_freqs = NULL;
+#endif
rcu_read_lock();
@@ -82,6 +87,40 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
*table = freq_table[0];
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ if (of_find_property(dev-of_node, boost-frequency, len)) {
Does this mean another block inside the cpu node ? Like this: ?
cpu@0 {
compatible = arm,cortex-a9;
reg = 0;
next-level-cache = L2;
operating-points =
/* kHzuV */
792000 110
396000 95
198000 85
;
boost-frequency =
792000
198000
;
};
I think it we might better add another field in the opp block as these
OPPs are rather boost one..
@Rob/Rafael: Opinion please ..
+ if (len == 0 || (len (sizeof(u32) - 1)) != 0) {
+ dev_err(dev, %s: invalid boost frequency\n,
__func__);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ boost_freqs = kzalloc(len, GFP_KERNEL);
+ if (!boost_freqs) {
+ dev_warn(dev, %s: no memory for boost freq table\n,
+ __func__);
+ ret = -ENOMEM;
+ goto out;
+ }
+ of_property_read_u32_array(dev-of_node, boost-frequency,
+ boost_freqs, len / sizeof(u32));
+ }
+
+ for (j = 0; j len / sizeof(u32) boost_freqs; j++) {
Why is this present outside of above if {} ? as boost_freqs is guaranteed to
be NULL without that.
+ for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END;
i++) {
+ if (boost_freqs[j] == freq_table[i].frequency) {
Use cpufreq_frequency_table_get_index() instead.
+ freq_table[i].flags |= CPUFREQ_BOOST_FREQ;
+ break;
+ }
+ }
+ if (freq_table[i].frequency == CPUFREQ_TABLE_END)
+ pr_err(%s: invalid boost frequency %d\n,
+ __func__, boost_freqs[j]);
+ }
+
+ kfree(boost_freqs);
+#endif
+
out:
rcu_read_unlock();
if (ret)
--
1.7.4.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 v4 1/8] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
On 14 May 2014 06:41, Thomas Abraham ta.oma...@gmail.com wrote:
From: Thomas Abraham thomas...@samsung.com
Lookup for the optional boost-frequency property in cpu0 node and if
available, enable support for boost mode frequencies. The frequencies
usable in boost mode are determined while preparing the cpufreq table
from the list of operating points available.
Cc: Shawn Guo shawn@linaro.org
Cc: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |2 ++
drivers/cpufreq/Kconfig| 11 +++
drivers/cpufreq/cpufreq-cpu0.c |5 +
3 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index f055515..60f321a 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -19,6 +19,8 @@ Optional properties:
- cooling-min-level:
- cooling-max-level:
Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
+- boost-frequency:
+ Please refer to
Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
Examples:
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 1fbe11f..0ca4485 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -194,6 +194,17 @@ config GENERIC_CPUFREQ_CPU0
If in doubt, say N.
+config GENERIC_CPUFREQ_CPU0_BOOST
Get rid of this.. just not required.
+ bool Boost frequency support for generic CPU0 cpufreq driver
+ depends on GENERIC_CPUFREQ_CPU0
+ select CPU_FREQ_BOOST_SW
+ help
+ This enables support for software managed overclocking (BOOST). It
+ allows usage of special frequencies (those beyond the normal
operating
+ frequencies).
+
+ If in doubt, say N.
+
menu x86 CPU frequency scaling drivers
depends on X86
source drivers/cpufreq/Kconfig.x86
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 1bf6bba..e6c21a8 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -194,6 +194,11 @@ static int cpu0_cpufreq_probe(struct platform_device
*pdev)
transition_latency += ret * 1000;
}
+#ifdef CONFIG_GENERIC_CPUFREQ_CPU0_BOOST
+ if (of_find_property(cpu_dev-of_node, boost-frequency, NULL))
Lets see what happens to the other thread for this.
+ cpu0_cpufreq_driver.boost_supported = true;
+#endif
+
ret = cpufreq_register_driver(cpu0_cpufreq_driver);
if (ret) {
pr_err(failed register driver: %d\n, ret);
--
1.7.4.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 v4 2/8] clk: samsung: change scope of samsung clock lock to global
On 14 May 2014 06:41, Thomas Abraham ta.oma...@gmail.com wrote: From: Thomas Abraham thomas...@samsung.com Access to samsung clock lock is required to support newer samsung specific clock types. So change the scope of the samsung clock lock to global. And Maybe bit more detail on why exactly it should be available outside this file. -- 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 v4 8/8] cpufreq: exynos: remove all exynos specific cpufreq driver support
On 14 May 2014 06:41, Thomas Abraham ta.oma...@gmail.com wrote: From: Thomas Abraham thomas...@samsung.com Exynos4210, Exynos4x12 and Exynos5250 based platforms have switched over to use cpufreq-cpu0 driver for cpufreq functionality. So the Exynos specific cpufreq drivers for these platforms can be removed. Signed-off-by: Thomas Abraham thomas...@samsung.com --- drivers/cpufreq/Kconfig.arm | 52 - drivers/cpufreq/Makefile |4 - drivers/cpufreq/exynos-cpufreq.c | 209 - drivers/cpufreq/exynos-cpufreq.h | 91 --- drivers/cpufreq/exynos4210-cpufreq.c | 157 - drivers/cpufreq/exynos4x12-cpufreq.c | 211 -- drivers/cpufreq/exynos5250-cpufreq.c | 183 - 7 files changed, 0 insertions(+), 907 deletions(-) I *loved* this :) Ack Ack Ack ... -- 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] cpufreq / OPP: Allow boost frequency to be looked up from device tree
On Tue, May 13, 2014 at 10:40 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 14 May 2014 06:32, Thomas Abraham ta.oma...@gmail.com wrote:
[...]
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ if (of_find_property(dev-of_node, boost-frequency, len)) {
Does this mean another block inside the cpu node ? Like this: ?
cpu@0 {
compatible = arm,cortex-a9;
reg = 0;
next-level-cache = L2;
operating-points =
/* kHzuV */
792000 110
396000 95
198000 85
;
boost-frequency =
792000
198000
;
};
I think it we might better add another field in the opp block as these
OPPs are rather boost one..
If we change the meaning to be:
operating-points =
/* kHzuV boost? */
792000 110 1
396000 950
We are adding a modifier to the OPP definition here and does imply
every platform which may or maynot require boost need to indicate
that - basically fails at least my least common description for a
generic definition. As I had indicated in other threads - we are back
to the discussion of additional properties to an OPP..
Option 1:
- describe modifiers separately (as in boost-frequencies) - that
operate based on data from opp table.
Option 2:
- keep adding to the description of opp as time goes by - every SoC
has it's own set of quirks that are needed for an OPP - I know that at
TI, we have certain OPPs that can only be enabled *if* custom
hardware driver is enabled, and similar stories. - yet another
example is enable the OPP if efuse X, bit Y is set.
Personally, looking at the various descriptions and bL, cpu-idle
states dependencies on OPPs, etc.. Option 2 is a non-scalable
approach.
[...]
--
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] ARM: EXYNOS: Map SYSRAM through generic SRAM bindings
Tushar Behera wrote: On 05/13/2014 03:37 PM, Paul Bolle wrote: Kukjin, On Tue, 2014-05-13 at 12:12 +0900, Kukjin Kim wrote: Tomasz Figa wrote: You mean s/sram/sysram/ in compatible strings of Exynos-specific reserved areas? If yes, I'm fine, it might be even better. Just remember to update documentation in patch 2/2 as well. Done. If any problems in my tree, please let me know. It seems this one just hit linux-next (in next-20140513) as ARM: EXYNOS: Map SYSRAM through generic DT bindings. Its commit now contains this hunk: --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -843,6 +843,7 @@ config ARCH_EXYNOS select HAVE_S3C_RTC if RTC_CLASS select NEED_MACH_MEMORY_H select SPARSE_IRQ + select SYSRAM select USE_OF help Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5) But there's no Kconfig symbol SYSRAM. However, there is a Kconfig symbol SRAM. Did you perhaps do one s/sram/sysram/ too many on the original patch? Also the compatible string name should be 'mmio-sram' on the DTS files. Paul and Tushar, Thanks for the pointing out. Let me fix them, config name and compatible string. - 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 v6 0/5] MCPM backend for Exynos5420
Hi Nicolas,
On Tue, May 13, 2014 at 11:25 PM, Nicolas Pitre
nicolas.pi...@linaro.org wrote:
On Tue, 13 May 2014, Abhilash Kesavan wrote:
This is v6 of the series adding MCPM backend support for SMP secondary boot
and core switching on Samsung's Exynos5420. The patches are based on the mcpm
support added for Exynos5420 in the Chromium kernel repository here:
https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/chromeos-3.8
The patches have been prepared on Kukjin Kim's for-next branch and tested on
SMDK5420 EVT1 as well as an exynos5420 based chromebook (peach-pit) using the
/dev/b.L_switcher user interface. Secondary core boot-up has also been
tested
on both the boards.
OK... Now it is time for real testing. :-)
The /dev/b.L_switcher interface tests the switcher. Here you really
want to hammer the MCPM functionalities and especially your backend code
as hard as possible. I therefore recommend the following test script:
-- 8
#!/bin/bash
echo 0 /sys/kernel/bL_switcher/active
sleep 1
pids=
for cpu in /sys/devices/system/cpu/cpu?/online; do
{ cpu_nr=${cpu:27:1}
while true; do
echo 1 $cpu 2 /dev/null
sleep .00$RANDOM
val1=$(cat $cpu)
echo 0 $cpu 2 /dev/null
sleep .00$RANDOM
val0=$(cat $cpu)
[ $val1 = 1 -a $val0 = 0 ] echo -n $cpu_nr
done
}
pids=$pids $!
done
trap kill $pids; echo 0 15
wait $pids
-- 8
Leave this running for a couple hours making sure you see all CPU
numbers being printed. The printing order will be random, but each CPU
number should continuously appear.
I tried this script and I get two errors:
1) can't create /sys/devices/system/cpu/cpu//online: nonexistent directory
2) sleep: invalid number '.0026736'
For 1) the cpu number is not being appended. if I give a particular
cpu in the script then hotplug in/out works fine.
For 2) a constant msleep 10 works.
Is it OK for me to modify the script to hotplug in/off a randomly chosed core ?
Regards,
Abhilash
Nicolas
--
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 5/6] ARM: EXYNOS: Enable multi-platform build support
Olof Johansson wrote: On Tue, May 13, 2014 at 2:15 AM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 13 May 2014 13:37:33 Kukjin Kim wrote: Arnd Bergmann wrote: On Tuesday 22 April 2014, Olof Johansson wrote: I don't think there's a point in keeping this around. A single-platform config is just enabling a single platform in the config, it's not a specific option. I don't think any of the other platforms use anything like this today. The only one doing that is shmobile, but only because they have some SoCs that are multiplatform capable and some that are not. This isn't the case for Exynos, so it should no longer be needed. When I originally created this patch 18 months ago, there were a number of drivers that broke when multiplatform got enabled. Now the cpufreq driver is the only one left, but it seems that it will make it for 3.16, and I wouldn't wait for it if it doesn't. Let's just do multiplatform-only. In my position in S.LSI, I'd like to keep the current ARCH_EXYNOS4 and EXYNOS5 because IMHO selecting each series would be helpful on real product, multiplatform is available though. Additionally EXYNOS3 is being added. It's true we can support exynos-multiplatform even though above options are included... I think we are talking about different questions here: Thanks for your clarification. What Olof and I mean is we don't want to have an ARCH_EXYNOS_SINGLE option that is there for building EXYNOS but not allowing any other SoC. Yes and agreed ;-) Yes. i.e. the only way forward is multiplatform _only_. _BUT_ you can choose to disable all other platforms in a kernel, and thus turn it into a single-platform build. That's fine. What we don't want is added logic like the EXYNOS_SINGLE Kconfig was, just to do that. Sure. What I think you mean is that you want the individual EXYNOS versions to be separate Kconfig options, so you can build a kernel that supports EXYNOS4 but not EXYNOS5 if you want to. This is totally fine as far as I'm concerned, and it's not directly related to the first point. OK, thanks :-) I'm also OK with that, but please don't make it more granular than per family if you can avoid it. Sure. Note that if you enable LPAE, you will still only be able to build EXYNOS5 after the patch, but then you can have it in the same kernel as e.g. Tegra4 and Snapdragon 600. Yep, and that's as expected. OK. Thanks, 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
