Re: [PATCH v8 1/2] phy: Add new Exynos5 USB 3.0 PHY driver

[Kishon Vijay Abraham I]

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  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: [PATCH v8 1/2] phy: Add new Exynos5 USB 3.0 PHY driver

[Vivek Gautam]

Hi Kishon,


On Mon, May 12, 2014 at 6:33 PM, Kishon Vijay Abraham I  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 R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/2] [media] v4l: Add source change event

[Arun Kumar K]

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 
---
 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 @@
   
 
 
+
+  struct v4l2_event_src_change
+  
+   &cs-str;
+   
+ 
+   __u32
+   changes
+   
+ A bitmask that tells what has changed. See .
+   
+ 
+   
+  
+
+
 
   Changes
   
@@ -270,6 +286,22 @@

   
 
+
+
+  Source Changes
+  
+   &cs-def;
+   
+ 
+   V4L2_EVENT_SRC_CH_RESOLUTION
+   0x0001
+   This event gets triggered when a resolution change is
+   detected at runtime. This can typically come from a video decoder.
+   
+ 
+   
+  
+
   
   
 &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 @@

  
  
+   V4L2_EVENT_SOURCE_CHANGE
+   5
+   
+ This 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 id
+  matches the pad / input index from which you want to receive
+  events.
+
+  This event has a &v4l2-event-source-change; associated
+ with it. The changes 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.
+   
+ 
+ 
V4L2_EVENT_PRIVATE_START
0x0800
Base event number for driver-private events.
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,
+   const struct v4l2_event_subscription *sub)
+{
+   if (sub->type == V4L2_EVENT_SOURCE_CHANGE)
+   return v4l2_event_subscribe(fh, sub, 0, &v4l2_event_src_ch_ops);
+   return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(v4l2_src_change_event_subscribe);
+
+int v4l2_src_change_event_subdev_subscribe(struct v4l2_subdev *sd,
+   struct v4l2_fh *fh, struct v4l2_event_subscription *sub)
+{
+   return v4l2_src_change_event_subscribe(fh, sub);
+}
+EXPORT_SYMBOL_GPL(v4l2_src_change_event_subdev_subscribe);
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index be05d01..1ab9045 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.

[PATCH v4 2/2] [media] s5p-mfc: Add support for resolution change event

[Arun Kumar K]

From: Pawel Osciak 

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 
Signed-off-by: Arun Kumar K 
---
 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;
+   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;
}
-- 
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/2] Add resolution change event

[Arun Kumar K]

This patchset adds a source_change event to the v4l2-events.
This can be used for notifying the userspace about runtime
format changes happening on video nodes / pads like resolution
change in video decoder.

Changes from v3
--
- Addressed comments from Laurent / Hans
  https://patchwork.kernel.org/patch/4135731/

Changes from v2
---
- Event can be subscribed on specific pad / port as
  suggested by Hans.

Changes from v1
---
- Addressed review comments from Hans and Laurent
  https://patchwork.kernel.org/patch/4000951/

Arun Kumar K (1):
  [media] v4l: Add source change event

Pawel Osciak (1):
  [media] s5p-mfc: Add support for resolution change event

 Documentation/DocBook/media/v4l/vidioc-dqevent.xml |   32 +
 .../DocBook/media/v4l/vidioc-subscribe-event.xml   |   19 +++
 drivers/media/platform/s5p-mfc/s5p_mfc.c   |7 
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |2 ++
 drivers/media/v4l2-core/v4l2-event.c   |   36 
 include/media/v4l2-event.h |4 +++
 include/uapi/linux/videodev2.h |8 +
 7 files changed, 108 insertions(+)

-- 
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 v2 0/4] ARM: S3C24XX: cleanup debug macro/earlyprintk

[Kukjin Kim]

Heiko Stübner wrote:
> 

[...]

> > >
> > > Heiko Stuebner (4):
> > >   ARM: compressed/head.S: remove s3c24xx special case
> > >   ARM: S3C24XX: trim down debug uart handling
> > >   ARM: S3C24XX: use generic DEBUG_UART_PHY/_VIRT in debug macro
> > >   ARM: S3C24XX: move debug-macro.S into the common space
> > >
> > >  arch/arm/Kconfig.debug   |  54 +++-
> > >  arch/arm/boot/compressed/head.S  |   5 --
> > >  arch/arm/include/debug/s3c24xx.S |  46 +++
> > >  arch/arm/mach-s3c24xx/Kconfig|  28 ---
> > >  arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 101 --
> 
> > >
> > > -
> > >
> > >  5 files changed, 98 insertions(+), 136 deletions(-)
> > >  create mode 100644 arch/arm/include/debug/s3c24xx.S
> > >  delete mode 100644 arch/arm/mach-s3c24xx/include/mach/debug-macro.S
> > >
> > > --
> > > 1.9.0
> >
> > Basically I'm OK on this series but need to get review from Russell?
> 
> Russell pointed out a bad decision on my part in v1, so I guess he is
> aware of
> this series :-) . I've also added a...@kernel.org now, so they can
complain,
> if
> anything is done wrong [should've probably done that from the beginning].
> 
OK, I will apply this series.

Russell, do you have any comments on this series, please kindly let us know.

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

RE: [PATCH] ARM: dts: Remove vmmc-supply for mmc@12220000 on arndale-octa board

[Kukjin Kim]

Javi Merino wrote:
> 
> Hi Sachin,

Hi Sachin and Javi,

[...]

> >
> > You need the following patch to mount the MMC. Without this the
> regulator will
> > not be enabled which is required by MMC.
> >
> > ARM: exynos_defconfig: Enable HS-I2C
> > http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/27527
> 
> Yes, that's the bit that I was missing.  With that patch 3.15-rc2
> boots on my Arndale Octa.
> 
> > Kukjin, can you please apply this patch?
> 
> You can add my Tested-by for Arndale Octa.
> 
OK, agreed. I will apply the enable HS-I2C on exynos_defconfig with Javi's test 
tag.

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

RE: [PATCHv2] mmc: dw_mmc: change to use recommended reset procedure

[Kukjin Kim]

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)

Above changes should be put after following '---'.

> 
> Signed-off-by: Sonny Rao 
> Signed-off-by: Yuvaraj Kumar C D 
> ---

Here.

- Kukjin

>  drivers/mmc/host/dw_mmc.c | 55
> ++-
>  drivers/mmc/host/dw_mmc.h |  1 +
>  2 files changed, 55 insertions(+), 1 deletion(-)

--
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

[Seungwon Jeon]

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.
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 
> Signed-off-by: Yuvaraj Kumar C D 
> ---
>  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.

> + 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?

> + mci_writel(host, RINTSTS, 0x);
> +
> + /* if using dma we wait for dma_req to clear */
> + if (host->use_dma) {
> + unsigned long timeout = jiffies + msecs_to_jiffies(500);
> + u32 status;
> + do {
> + status = mci_readl(host, STATUS);
> + if (!(status & SDMMC_STATUS_DMA_REQ))
> + break;
> + cpu_relax();
What did you intend here?
If you intent busy-wait, how about using sleep instead?

> + } while (time_before(jiffies, timeout));
> +
> + if (status & SDMMC_STATUS_DMA_REQ) {
> + dev_err(host->dev,
> + "%s: Timeout waiting for dma_req to "
> + "clear during reset", __func__);
> + return false;
> + }
> +
> + /* when using DMA next we reset the fifo again */
> + dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET);
> + }
> + } else {
> + dev_err(host->dev, "%s: Reset bits didn't clear", __func__);
If ciu_reset is cleared, clk update below is needed?

Thanks,
Seungwon Jeon

> + return false;
> + }
> +
> +#ifdef CONFIG_MMC_DW_IDMAC
> + /* It is also recommended that we reset and reprogram idmac */
> + dw_mci_idmac_reset(host);
> +#endif
> +
> + /* After a CTRL reset we need to have CIU set clock registers  */
> + mci_send_cmd(host->cur_slot, SDMMC_CMD_UPD_CLK, 0);
> +
> + return true;
>  }
> 
>  static inline bool dw_mci_ctrl_all_reset(struct dw_mci *host)
> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
> index 6bf24ab..2505804 100644
> --- a/drivers/mmc/host/dw_mmc.h
> +++ b/drivers/mmc/host/dw_mmc.h
> @@ -129,6 +129,7 @@
>  #define SDMMC_CMD_INDX(n)((n) & 0x1F)
>  /* Status register defines */
>  #define SDMMC_GET_FCNT(x)(((x)>>17) & 0x1FFF)
> +#define SDMMC_STATUS_DMA_REQ BIT(31)
>  /* FIFOTH register defines */
>  #define SDMMC_SET_FIFOTH(m, r, t)(((m) & 0x7) << 28 | \
>((r) & 0xFFF) << 16 | \
> --
> 1.9.1.423.g4596e3a
> 
> --
> To unsubscrib

RE: [PATCH] mmc: dw_mmc: Make sure we don't get stuck when we get an error

[Seungwon Jeon]

Hi Doug,

On Tue, May 13, 2014, Doug Anderson wrote:
> Seungwon,
> 
> On Sat, May 10, 2014 at 7:11 AM, Seungwon Jeon  wrote:
> > On Fri, May 09, 2014, Sonny Rao wrote:
> >> On Thu, May 8, 2014 at 2:42 AM, Yuvaraj Kumar  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
> >> >  wrote:
> >> >> From: Doug Anderson 
> >> >>
> >> >> 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.

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?

Thanks,
Seungwon Jeon
> 
> 
> >> >> 2. Fix it so that if we detect that we've got an error in the "data
> >> >>busy" state and we're not going to do anything else we end the
> >> >>request and unblock anyone waiting.
> >> >>
> >> >> Signed-off-by: Doug Anderson 
> >> >> Signed-off-by: Yuvaraj Kumar C D 
> >> >> ---
> >> >>  drivers/mmc/host/dw_mmc.c |   47 
> >> >> +
> >> >>  1 file changed, 47 insertions(+)
> >> >>
> >> >> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> >> >> index 1d77431..4c589f1 100644
> >> >> --- a/drivers/mmc/host/dw_mmc.c
> >> >> +++ b/drivers/mmc/host/dw_mmc.c
> >> >> @@ -1300,6 +1300,14 @@ static void dw_mci_tasklet_func(unsigned long 
> >> >> priv)
> >> >> /* fall through */
> >> >>
> >> >> case STATE_SENDING_DATA:
> >> >> +   /*
> >> >> +* We could get a data error and never a 
> >> >> transfer
> >> >> +* complete so we'd better check for it here.
> >> >> +*
> >> >> +* Note that we don't really care if we also 
> >> >> got a
> >> >> +* transfer complete; stopping the DMA and 
> >> >> sending an
> >> >> +* abort won't hurt.
> >> >> +*/
> >> >> if (test_and_clear_bit(EVENT_DATA_ERROR,
> >> >>&host->pending_events)) {
> >> >> dw_mci_stop_dma(host);
> >> >> @@ -1313,7 +1321,29 @@ static void dw_mci_tasklet_func(unsigned long 
> >> >> priv)
> >> >> break;
> >> >>
> >> >> set_bit(EVENT_XFER_COMPLETE, 
> >> >> &host->completed_events);
> >> >> +
> >> >> +   /*
> >> >> +* Handle an EVENT_DATA_ERROR that might have 
> >> >> shown up
> >> >> +* before the transfer completed.  This might 
> >> >> not have
> >> >> +* been caught by the check above because the 
> >> >> interrupt
> >> >> +* could have gone off between the previous 
> >> >> check and
> >> >> +* the check for transfer complete.
> >> >> +*
> >> >> +* Technically this ought not be needed 
> >> >> assuming we
> >> >> +* get a DATA_COMPLETE eventually (we'll notice 
> >> >> the
> >> >> +

RE: [PATCH 5/6] ARM: EXYNOS: Enable multi-platform build support

[Kukjin Kim]

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...

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

RE: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420

[Kukjin Kim]

Tushar Behera wrote:

[...]

> 
> Having tried all these options, I still feel removing mau_pd node from
> device tree is the only option.

Agreed. I will apply this fix if nobody has any idea about that at this
moment.

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

Re: [PATCH 2/2] ARM: dts: enable fimd for exynos5800 based peach-pi board

[Rahul Sharma]

Thanks Jingoo Han.

Hi Kukjin,

Please consider both of these series for your tree.

1) http://www.spinics.net/lists/arm-kernel/msg329697.html
2) http://www.spinics.net/lists/arm-kernel/msg330291.html

Regards,
Rahul Sharma

On 13 May 2014 06:44, Jingoo Han  wrote:
> On Monday, May 12, 2014 3:45 PM, Rahul Sharma wrote:
>>
>> From: Rahul Sharma 
>>
>> Enable FIMD for peach-pi board.
>>
>> Signed-off-by: Rahul Sharma 
>
> Reviewed-by: Jingoo Han 
>
> Best regards,
> Jingoo Han
>
>> ---
>>  arch/arm/boot/dts/exynos5800-peach-pi.dts |5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
>> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> index 426705a..cccacdd 100644
>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> @@ -157,6 +157,11 @@
>>   };
>>  };
>>
>> +&fimd {
>> + status = "okay";
>> + samsung,invert-vclk;
>> +};
>> +
>>  &hsi2c_9 {
>>   status = "okay";
>>   clock-frequency = <40>;
>> --
>> 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 v3 1/2] ARM: EXYNOS: Map SYSRAM through generic SRAM bindings

[Kukjin Kim]

Tomasz Figa wrote:
> 
> Hi Kukjin,
> 
Hi,

> On 09.05.2014 04:14, Kukjin Kim wrote:
> > Tomasz Figa wrote:
> >>
> >> Hi Sachin,
> >>
> >> On 08.05.2014 06:16, Sachin Kamat wrote:
> >>> Instead of hardcoding the SYSRAM details for each SoC,
> >>> pass this information through device tree (DT) and make
> >>> the code SoC agnostic. Generic SRAM bindings are used
> >>> for achieving this.
> >>>
> >>> Signed-off-by: Sachin Kamat 
> >>> Acked-by: Arnd Bergmann 
> >>> Acked-by: Heiko Stuebner 
> >>> ---
> >>> Changes since v2.
> >>> * Updated sysram node for Universal C210 board - Thanks to
> >>> Tomasz Figa for testing and updating the same.
> >>> * Added error handling code.
> >>> * Break if matching node found.
> >>> * Remove unnecessary error messages.
> >>>
> >>> This patch is based on linux next (next-20140501) on top of
> >>> my Kconfig consolidation patch
> >>> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/28642
> >>>
> >>> Tested on 4210/4412 Origen, 5250/5420 Arndale and SMDK5420 boards.
> >>> ---
> >>>   arch/arm/Kconfig|1 +
> >>>   arch/arm/boot/dts/exynos4210-universal_c210.dts |   15 ++
> >>>   arch/arm/boot/dts/exynos4210.dtsi   |   18 +++
> >>>   arch/arm/boot/dts/exynos4x12.dtsi   |   18 +++
> >>>   arch/arm/boot/dts/exynos5250.dtsi   |   18 +++
> >>>   arch/arm/boot/dts/exynos5420.dtsi   |   18 +++
> >>>   arch/arm/mach-exynos/common.h   |1 +
> >>>   arch/arm/mach-exynos/exynos.c   |   64
> > --
> >> -
> >>>   arch/arm/mach-exynos/firmware.c |8 ++-
> >>>   arch/arm/mach-exynos/include/mach/map.h |7 ---
> >>>   arch/arm/mach-exynos/platsmp.c  |   56
> > ++--
> >>>   11 files changed, 148 insertions(+), 76 deletions(-)
> >>>
> >>
> >> Looks good, thanks.
> >>
> >> Reviewed-by: Tomasz Figa 
> >>
> > Looks good to me but I think, we need to change the name of 'sram'
> because
> > it can cause some confusing, actually it is not matching _real_ sram
> area on
> > the SoCs. When we upstreamed regarding patch, I decided the name to use
> > 'SYSRAM', it was called another name in datasheet though. So, I'd like
> to
> > use 'sysram' instead of 'sram' as we used before.
> >
> > I will change the name when I apply this series in this weekend, if you
> guys
> > have no objection.
> 
> 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.

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

RE: [PATCH v5 2/5] ARM: EXYNOS: use generic exynos cpu power control functions

[Kukjin Kim]

Abhilash Kesavan wrote:
> 
> From: Leela Krishna Amudala 
> 
> 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 

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.

- 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 v5 1/5] ARM: EXYNOS: Add generic cpu power control functions for all exynos based SoCs

[Kukjin Kim]

Abhilash Kesavan wrote:
> 
+ Jonghwan Choi, Seungkon Hwang

> From: Leela Krishna Amudala 
> 
> 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 

In this case, Abhilash's signed-off-by should be added here.

> ---
>  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.

> +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

> 
>  #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.

> +#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 

> +
>  /* 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

[PATCHv2] mmc: dw_mmc: change to use recommended reset procedure

[Sonny Rao]

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 
Signed-off-by: Yuvaraj Kumar C D 
---
 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
+   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.
+*/
+   mci_writel(host, RINTSTS, 0x);
+
+   /* if using dma we wait for dma_req to clear */
+   if (host->use_dma) {
+   unsigned long timeout = jiffies + msecs_to_jiffies(500);
+   u32 status;
+   do {
+   status = mci_readl(host, STATUS);
+   if (!(status & SDMMC_STATUS_DMA_REQ))
+   break;
+   cpu_relax();
+   } while (time_before(jiffies, timeout));
+
+   if (status & SDMMC_STATUS_DMA_REQ) {
+   dev_err(host->dev,
+   "%s: Timeout waiting for dma_req to "
+   "clear during reset", __func__);
+   return false;
+   }
+
+   /* when using DMA next we reset the fifo again */
+   dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET);
+   }
+   } else {
+   dev_err(host->dev, "%s: Reset bits didn't clear", __func__);
+   return false;
+   }
+
+#ifdef CONFIG_MMC_DW_IDMAC
+   /* It is also recommended that we reset and reprogram idmac */
+   dw_mci_idmac_reset(host);
+#endif
+
+   /* After a CTRL reset we need to have CIU set clock registers  */
+   mci_send_cmd(host->cur_slot, SDMMC_CMD_UPD_CLK, 0);
+
+   return true;
 }
 
 static inline bool dw_mci_ctrl_all_reset(struct dw_mci *host)
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 6bf24ab..2505804 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -129,6 +129,7 @@
 #define SDMMC_CMD_INDX(n)  ((n) & 0x1F)
 /* Status register defines */
 #define SDMMC_GET_FCNT(x)  (((x)>>17) & 0x1FFF)
+#define SDMMC_STATUS_DMA_REQ   BIT(31)
 /* FIFOTH register defines */
 #define SDMMC_SET_FIFOTH(m, r, t)  (((m) & 0x7) << 28 | \
 ((r) & 0xFFF) << 16 | \
-- 
1.9.1.423.g4596e3a

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ARM: dts: enable fimd for exynos5800 based peach-pi board

[Jingoo Han]

On Monday, May 12, 2014 3:45 PM, Rahul Sharma wrote:
> 
> From: Rahul Sharma 
> 
> Enable FIMD for peach-pi board.
> 
> Signed-off-by: Rahul Sharma 

Reviewed-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  arch/arm/boot/dts/exynos5800-peach-pi.dts |5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index 426705a..cccacdd 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -157,6 +157,11 @@
>   };
>  };
> 
> +&fimd {
> + status = "okay";
> + samsung,invert-vclk;
> +};
> +
>  &hsi2c_9 {
>   status = "okay";
>   clock-frequency = <40>;
> --
> 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 1/2] ARM: dts: enable display controller for exynos5800 based peach-pi board

[Jingoo Han]

On Monday, May 12, 2014 3:45 PM, Rahul Sharma wrote:
> 
> From: Rahul Sharma 
> 
> Enable display controller with timing information for 1080p
> panel in Exynos5800 peach-pi board.
> 
> Signed-off-by: Rahul Sharma 

Reviewed-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  arch/arm/boot/dts/exynos5800-peach-pi.dts |   36 
> +
>  1 file changed, 36 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index 742655b..426705a 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -72,6 +72,13 @@
>   samsung,pin-pud = <0>;
>   samsung,pin-drv = <0>;
>   };
> +
> + dp_hpd_gpio: dp_hpd_gpio {
> + samsung,pins = "gpx2-6";
> + samsung,pin-function = <0>;
> + samsung,pin-pud = <3>;
> + samsung,pin-drv = <0>;
> + };
>  };
> 
>  &rtc {
> @@ -121,6 +128,35 @@
>   };
>  };
> 
> +&dp {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&dp_hpd_gpio>;
> + samsung,color-space = <0>;
> + samsung,dynamic-range = <0>;
> + samsung,ycbcr-coeff = <0>;
> + samsung,color-depth = <1>;
> + samsung,link-rate = <0x0a>;
> + samsung,lane-count = <2>;
> + samsung,hpd-gpio = <&gpx2 6 0>;
> +
> + display-timings {
> + native-mode = <&timing1>;
> +
> + timing1: timing@1 {
> + clock-frequency = <15066>;
> + hactive = <1920>;
> + vactive = <1080>;
> + hfront-porch = <60>;
> + hback-porch = <172>;
> + hsync-len = <80>;
> + vback-porch = <25>;
> + vfront-porch = <10>;
> + vsync-len = <10>;
> + };
> + };
> +};
> +
>  &hsi2c_9 {
>   status = "okay";
>   clock-frequency = <40>;
> --
> 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] mmc: dw_mmc: change to use recommended reset procedure

[Sonny Rao]

On Mon, May 12, 2014 at 2:44 PM, Sonny Rao  wrote:
> On Fri, May 9, 2014 at 8:36 PM, Sonny Rao  wrote:
>> On Fri, May 9, 2014 at 12:32 AM, Jaehoon Chung  
>> wrote:
>>> Hi, Sonny.
>>>
>>> You can discard the my previous some comment.
>>> As you mentioned, this reset sequence is recommended at Synopsys TRM.
>>>
>>> Add the minor question.
>>>
>>> On 05/09/2014 01:27 PM, Jaehoon Chung wrote:
 Hi, Sonny.

 I have checked the Synopsys TRM..

 On 05/09/2014 10:34 AM, Sonny Rao wrote:
> On Thu, May 8, 2014 at 6:15 PM, Jaehoon Chung  
> wrote:
>> On 05/08/2014 06:40 PM, Yuvaraj Kumar wrote:
>>> Any comments on this patch?
>>>
>>> On Wed, Mar 26, 2014 at 5:16 PM, Yuvaraj Kumar C D 
>>>  wrote:
 From: Sonny Rao 

 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.
 Without this patch, we could able to see eMMC was not detected after
 multiple reboots due to driver hangs while eMMC tuning for HS200.

 Signed-off-by: Sonny Rao 
 Signed-off-by: Yuvaraj Kumar C D 
 ---
  drivers/mmc/host/dw_mmc.c |   48 
 -
  drivers/mmc/host/dw_mmc.h |1 +
  2 files changed, 48 insertions(+), 1 deletion(-)

 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index 32dd81d..1d77431 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -2220,7 +2220,53 @@ 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.
 +* Note that this doesn't handle the "generic DMA" (not IDMAC) 
 case.
 +*/
>>
>> "not IDMAC" is confused..
>>
>
> The documentation describes three different possible modes.  There's a
> mode that doesn't use IDMAC but still does DMA.  But as far as I can
> tell this driver doesn't support that way.  We can just remove that
> wording if it's confusing.
>>>
>>> How did it know whether dma is generic DMA or not?
>>>
>>
>> That's a good question.  I wasn't sure whether the driver supported it
>> or not.  It looks like it definitely supports IDMAC through the
>> CONFIG_MMC_DW_IDMAC flag, but I wasn't sure if it was supported the
>> generic dma.  Maybe if CONFIG_MMC_DW_IDMAC isn't specified but
>> host->dma_ops is not NULL then we are using the generic dma mode.
>>
>
> 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.
>

In any case, whether on not anybody is using it, it looks like it's
not that hard to support this mode for reset (I was just lazy the
first time), we just need to add a flag to our reset.  I've made that
change and cleaned it up a little bit more and I'll resend this patch.

>
 +   if (dw_mci_ctrl_reset(host, SDMMC_CTRL_RESET | 
 SDMMC_CTRL_FIFO_RESET)) {
 +   unsigned long timeout = jiffies + 
 msecs_to_jiffies(500);
 +   u32 status, rint;
 +
 +   /* if using dma we wait for dma_req to clear */
 +   if (host->using_dma) {
 +   do {
 +   status = mci_readl(host, STATUS);
 +   if (!(status & SDMMC_STATUS_DMA_REQ))
 +   break;
 +   cpu_relax();
 +   } while (time_before(jiffies, timeout));
 +
 +   if (status & SDMMC_STATUS_DMA_REQ)
 +   dev_err(host->dev,
 +   "%s: Timeout waiting for 
 dma_req to "
 +   "clear during reset", 
 __func__);
 +
 +   /* when using DMA next we reset the fifo again 
 */
 +   dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET);
 +   }
 +   /*
 +* In all cases we clear the RAWINTS register to clear 
 any
 +* interrupts.
 +*/
 +   rint = mci_readl(host, RINTSTS);
 +   rint = rint & (~mci_readl(host, MINTSTS));

Re: [PATCH v2.1 3/9] ARM: S3C24XX: enable usage of common dclk if common clock framework is enabled

[Heiko Stübner]

Hi Kukjin,

Am Dienstag, 13. Mai 2014, 07:47:57 schrieb Kukjin Kim:
> On 05/10/14 08:33, Heiko Stübner wrote:
> > Hi Tomasz,
> > 
> > It seems this one just hit linux-next (in next-20140509).
>  
>  Which is bad, because:
>  a) it conflicts with patches already applied in samsung-clk tree,
> >>> 
> >>> I remember seeing patches regarding more than one clk-samsung clock
> >>> providers. Do you need any additional changes for s3c24xx from me for
> >>> this?
> >> 
> >> Yes, that's the problem here. If you could do it, I would appreciate it,
> >> but if you don't have time then I can handle this. The changes needed
> >> are mostly trivial - basically every common samsung_clk function gets
> >> new argument to a context structure. The branch to base on would be
> >> for_3.16/exynos5260 in samsung-clk tree.
> 
> I think, would be better if we could fix the conflicts with Hekio's
> additional patches...basically nobody wants revert something for next
> tree once it is landed. But in this case, it's up to Tomasz...
> 
> Probably, Heiko resubmitted? Is it based on the branch Tomasz memtioned,
> I didn't check it yet?..
> 
> Tomasz, do you still want me to drop this series in samsung tree now?
> Additional patches would be helpful to me because other dependency i.e.,
> exynos5260...for me.

I submitted a v3 series yesterday, that is based on Tomasz' branch. This 
prevents build errors from happening. I'll let you two decide how you want to 
handle this :-)

I can also produce fixup patches if you two decide to keep the v2 series and 
just fix the conflicts.


Heiko
--
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.1 3/9] ARM: S3C24XX: enable usage of common dclk if common clock framework is enabled

[Kukjin Kim]

On 05/10/14 08:33, Heiko Stübner wrote:

Hi Tomasz,



It seems this one just hit linux-next (in next-20140509).


Which is bad, because:
a) it conflicts with patches already applied in samsung-clk tree,


I remember seeing patches regarding more than one clk-samsung clock
providers. Do you need any additional changes for s3c24xx from me for
this?


Yes, that's the problem here. If you could do it, I would appreciate it,
but if you don't have time then I can handle this. The changes needed
are mostly trivial - basically every common samsung_clk function gets
new argument to a context structure. The branch to base on would be
for_3.16/exynos5260 in samsung-clk tree.



I think, would be better if we could fix the conflicts with Hekio's 
additional patches...basically nobody wants revert something for next 
tree once it is landed. But in this case, it's up to Tomasz...


Probably, Heiko resubmitted? Is it based on the branch Tomasz memtioned, 
I didn't check it yet?..


Tomasz, do you still want me to drop this series in samsung tree now? 
Additional patches would be helpful to me because other dependency i.e., 
exynos5260...for me.



b) the DT binding added by patch 4/9 has not been acked .


I'm not 100% sure if this is necessary, as the binding is similar to most
other Samsung bindings and looking through recent clock binding changes I
didn't find any that seemed to have a special dt-maintainer ack -
including
Exynos ones. Also if I remember correctly there was this "if we don't
respond, carry on" policy around :-) .


Well, for me this could go as is, but rules should be followed and the
rules are ACK or 3 weeks and a ping without response. So we need to wait
at least to next Wednesday to bypass DT review.


so I only remembered the abbreviated version of this :-) [without the 3 weeks
requirement]. My guess is I should be able to adapt it to this change and also
fix the typo Paul found until then.


In my memory, not 3 weeks...maybe 1week or 10days?...

- 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 v2 0/6] Further cleanup and enable multiplat build

[Kukjin Kim]

On 05/05/14 00:35, Sachin Kamat wrote:

On 16 April 2014 19:21, Tomasz Figa  wrote:

Hi Sachin,


On 15.04.2014 11:28, Sachin Kamat wrote:


This series is based on latest linux-next and depends on the
following patch:
ARM: EXYNOS: Consolidate Kconfig entries
http://article.gmane.org/gmane.linux.kernel.samsung-soc/28642

Changes since v2:
Replaced patch 2, "ARM: EXYNOS: Staticize exynos_subsys"
with "ARM: EXYNOS: Remove exynos_subsys registration" as that
code is no more used.

Tested on Exynos4210, 4412, 5250 and 5420 based boards.

Arnd Bergmann (1):
ARM: EXYNOS: Enable multi-platform build support

Sachin Kamat (5):
ARM: EXYNOS: Remove duplicate lines in Makefile
ARM: EXYNOS: Remove exynos_subsys registration
ARM: EXYNOS: Migrate Exynos specific macros from plat to mach
ARM: EXYNOS: Remove unnecessary inclusion of cpu.h
ARM: multi_v7_defconfig: Enable Exynos platform

   arch/arm/Kconfig |   27 ++-
   arch/arm/configs/exynos_defconfig|2 +-
   arch/arm/configs/multi_v7_defconfig  |   10 +
   arch/arm/mach-exynos/Kconfig |   27 +++
   arch/arm/mach-exynos/Makefile|9 ++--
   arch/arm/mach-exynos/common.h|   72
++
   arch/arm/mach-exynos/cpuidle.c   |1 -
   arch/arm/mach-exynos/exynos.c|   13 --
   arch/arm/mach-exynos/hotplug.c   |2 -
   arch/arm/mach-exynos/platsmp.c   |2 -
   arch/arm/mach-exynos/pm.c|1 -
   arch/arm/mach-exynos/pmu.c   |2 -
   arch/arm/plat-samsung/Makefile   |3 ++
   arch/arm/plat-samsung/include/plat/cpu.h |   61
-
   14 files changed, 119 insertions(+), 113 deletions(-)



For the whole series:

Reviewed-by: Tomasz Figa


Kukjin,

Can you please apply the first 4 patches in this series for now?

Yes, I've applied the first 4 patches just now and I need to look at the 
5/6 patch...


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

Re: [PATCH] mmc: dw_mmc: Make sure we don't get stuck when we get an error

[Doug Anderson]

Seungwon,

On Sat, May 10, 2014 at 7:11 AM, Seungwon Jeon  wrote:
> On Fri, May 09, 2014, Sonny Rao wrote:
>> On Thu, May 8, 2014 at 2:42 AM, Yuvaraj Kumar  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
>> >  wrote:
>> >> From: Doug Anderson 
>> >>
>> >> 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?


>> >> 2. Fix it so that if we detect that we've got an error in the "data
>> >>busy" state and we're not going to do anything else we end the
>> >>request and unblock anyone waiting.
>> >>
>> >> Signed-off-by: Doug Anderson 
>> >> Signed-off-by: Yuvaraj Kumar C D 
>> >> ---
>> >>  drivers/mmc/host/dw_mmc.c |   47 
>> >> +
>> >>  1 file changed, 47 insertions(+)
>> >>
>> >> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> >> index 1d77431..4c589f1 100644
>> >> --- a/drivers/mmc/host/dw_mmc.c
>> >> +++ b/drivers/mmc/host/dw_mmc.c
>> >> @@ -1300,6 +1300,14 @@ static void dw_mci_tasklet_func(unsigned long priv)
>> >> /* fall through */
>> >>
>> >> case STATE_SENDING_DATA:
>> >> +   /*
>> >> +* We could get a data error and never a transfer
>> >> +* complete so we'd better check for it here.
>> >> +*
>> >> +* Note that we don't really care if we also got a
>> >> +* transfer complete; stopping the DMA and 
>> >> sending an
>> >> +* abort won't hurt.
>> >> +*/
>> >> if (test_and_clear_bit(EVENT_DATA_ERROR,
>> >>&host->pending_events)) {
>> >> dw_mci_stop_dma(host);
>> >> @@ -1313,7 +1321,29 @@ static void dw_mci_tasklet_func(unsigned long priv)
>> >> break;
>> >>
>> >> set_bit(EVENT_XFER_COMPLETE, 
>> >> &host->completed_events);
>> >> +
>> >> +   /*
>> >> +* Handle an EVENT_DATA_ERROR that might have 
>> >> shown up
>> >> +* before the transfer completed.  This might not 
>> >> have
>> >> +* been caught by the check above because the 
>> >> interrupt
>> >> +* could have gone off between the previous check 
>> >> and
>> >> +* the check for transfer complete.
>> >> +*
>> >> +* Technically this ought not be needed assuming 
>> >> we
>> >> +* get a DATA_COMPLETE eventually (we'll notice 
>> >> the
>> >> +* error and end the request), but it shouldn't 
>> >> hurt.
>> >> +*
>> >> +* This has the advantage of sending the stop 
>> >> command.
>> >> +*/
>> >> +   if (test_and_clear_bit(EVENT_DATA_ERROR,
>> >> +  &host->pending_events)) {
>> >> +   dw_mci_stop_dma(host);
>> >> +   send_stop_abort(host, data);
>> >> +   state = STATE_DATA_ERROR;
>> >> +   break;
>> >> +   }
>> >> prev_state = state = STATE_DATA_BUSY;
>> >> +
>> >> /* fall through */
>> >>
>> >> case S

Re: [PATCH] mmc: dw_mmc: change to use recommended reset procedure

[Sonny Rao]

On Fri, May 9, 2014 at 8:36 PM, Sonny Rao  wrote:
> On Fri, May 9, 2014 at 12:32 AM, Jaehoon Chung  wrote:
>> Hi, Sonny.
>>
>> You can discard the my previous some comment.
>> As you mentioned, this reset sequence is recommended at Synopsys TRM.
>>
>> Add the minor question.
>>
>> On 05/09/2014 01:27 PM, Jaehoon Chung wrote:
>>> Hi, Sonny.
>>>
>>> I have checked the Synopsys TRM..
>>>
>>> On 05/09/2014 10:34 AM, Sonny Rao wrote:
 On Thu, May 8, 2014 at 6:15 PM, Jaehoon Chung  
 wrote:
> On 05/08/2014 06:40 PM, Yuvaraj Kumar wrote:
>> Any comments on this patch?
>>
>> On Wed, Mar 26, 2014 at 5:16 PM, Yuvaraj Kumar C D 
>>  wrote:
>>> From: Sonny Rao 
>>>
>>> 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.
>>> Without this patch, we could able to see eMMC was not detected after
>>> multiple reboots due to driver hangs while eMMC tuning for HS200.
>>>
>>> Signed-off-by: Sonny Rao 
>>> Signed-off-by: Yuvaraj Kumar C D 
>>> ---
>>>  drivers/mmc/host/dw_mmc.c |   48 
>>> -
>>>  drivers/mmc/host/dw_mmc.h |1 +
>>>  2 files changed, 48 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index 32dd81d..1d77431 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -2220,7 +2220,53 @@ 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.
>>> +* Note that this doesn't handle the "generic DMA" (not IDMAC) 
>>> case.
>>> +*/
>
> "not IDMAC" is confused..
>

 The documentation describes three different possible modes.  There's a
 mode that doesn't use IDMAC but still does DMA.  But as far as I can
 tell this driver doesn't support that way.  We can just remove that
 wording if it's confusing.
>>
>> How did it know whether dma is generic DMA or not?
>>
>
> That's a good question.  I wasn't sure whether the driver supported it
> or not.  It looks like it definitely supports IDMAC through the
> CONFIG_MMC_DW_IDMAC flag, but I wasn't sure if it was supported the
> generic dma.  Maybe if CONFIG_MMC_DW_IDMAC isn't specified but
> host->dma_ops is not NULL then we are using the generic dma mode.
>

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.


>>> +   if (dw_mci_ctrl_reset(host, SDMMC_CTRL_RESET | 
>>> SDMMC_CTRL_FIFO_RESET)) {
>>> +   unsigned long timeout = jiffies + msecs_to_jiffies(500);
>>> +   u32 status, rint;
>>> +
>>> +   /* if using dma we wait for dma_req to clear */
>>> +   if (host->using_dma) {
>>> +   do {
>>> +   status = mci_readl(host, STATUS);
>>> +   if (!(status & SDMMC_STATUS_DMA_REQ))
>>> +   break;
>>> +   cpu_relax();
>>> +   } while (time_before(jiffies, timeout));
>>> +
>>> +   if (status & SDMMC_STATUS_DMA_REQ)
>>> +   dev_err(host->dev,
>>> +   "%s: Timeout waiting for 
>>> dma_req to "
>>> +   "clear during reset", __func__);
>>> +
>>> +   /* when using DMA next we reset the fifo again 
>>> */
>>> +   dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET);
>>> +   }
>>> +   /*
>>> +* In all cases we clear the RAWINTS register to clear 
>>> any
>>> +* interrupts.
>>> +*/
>>> +   rint = mci_readl(host, RINTSTS);
>>> +   rint = rint & (~mci_readl(host, MINTSTS));
>>> you use the "status or temp" instead of rint. (you can reuse the variable.)
>>> And can use "status &= ~mci_readl(host,MINTSTS);"
>>>
>
> Just clear the RINTSTS register? why do you add these?
>

 This will look at what is not masked, and only clear those bits.
>>> Well, i known if clear the RINTSTS register,
>>> recommended to use "0xfff" and set the value for interrupt.
>>
>> Can be used "0xfff"?
>>
>
> Yeah we probably can.  We 

Re: [PATCH] mmc: dw_mmc: change to use recommended reset procedure

[Sonny Rao]

On Sat, May 10, 2014 at 7:08 AM, Seungwon Jeon  wrote:
> Hi Sonny,
>
> Can you separate procedure?
> Reset all are handled in fifo-reset.
> And ciu reset is always needed for error handling?

Yes according to the document in the "Controller/DMA/FIFO Reset Usage"
section, the controller_reset bit should be set in all cases, so I
don't think that it should be separated.

>
> Thanks,
> Seungwon Jeon
>
> On Sat, May 10, 2014, Sonny Rao wrote:
>> On Fri, May 9, 2014 at 12:32 AM, Jaehoon Chung  
>> wrote:
>> > Hi, Sonny.
>> >
>> > You can discard the my previous some comment.
>> > As you mentioned, this reset sequence is recommended at Synopsys TRM.
>> >
>> > Add the minor question.
>> >
>> > On 05/09/2014 01:27 PM, Jaehoon Chung wrote:
>> >> Hi, Sonny.
>> >>
>> >> I have checked the Synopsys TRM..
>> >>
>> >> On 05/09/2014 10:34 AM, Sonny Rao wrote:
>> >>> On Thu, May 8, 2014 at 6:15 PM, Jaehoon Chung  
>> >>> wrote:
>>  On 05/08/2014 06:40 PM, Yuvaraj Kumar wrote:
>> > Any comments on this patch?
>> >
>> > On Wed, Mar 26, 2014 at 5:16 PM, Yuvaraj Kumar C D 
>> >  wrote:
>> >> From: Sonny Rao 
>> >>
>> >> 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.
>> >> Without this patch, we could able to see eMMC was not detected after
>> >> multiple reboots due to driver hangs while eMMC tuning for HS200.
>> >>
>> >> Signed-off-by: Sonny Rao 
>> >> Signed-off-by: Yuvaraj Kumar C D 
>> >> ---
>> >>  drivers/mmc/host/dw_mmc.c |   48 
>> >> -
>> >>  drivers/mmc/host/dw_mmc.h |1 +
>> >>  2 files changed, 48 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> >> index 32dd81d..1d77431 100644
>> >> --- a/drivers/mmc/host/dw_mmc.c
>> >> +++ b/drivers/mmc/host/dw_mmc.c
>> >> @@ -2220,7 +2220,53 @@ 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.
>> >> +* Note that this doesn't handle the "generic DMA" (not 
>> >> IDMAC) case.
>> >> +*/
>> 
>>  "not IDMAC" is confused..
>> 
>> >>>
>> >>> The documentation describes three different possible modes.  There's a
>> >>> mode that doesn't use IDMAC but still does DMA.  But as far as I can
>> >>> tell this driver doesn't support that way.  We can just remove that
>> >>> wording if it's confusing.
>> >
>> > How did it know whether dma is generic DMA or not?
>> >
>>
>> That's a good question.  I wasn't sure whether the driver supported it
>> or not.  It looks like it definitely supports IDMAC through the
>> CONFIG_MMC_DW_IDMAC flag, but I wasn't sure if it was supported the
>> generic dma.  Maybe if CONFIG_MMC_DW_IDMAC isn't specified but
>> host->dma_ops is not NULL then we are using the generic dma mode.
>>
>> >>>
>> >> +   if (dw_mci_ctrl_reset(host, SDMMC_CTRL_RESET | 
>> >> SDMMC_CTRL_FIFO_RESET)) {
>> >> +   unsigned long timeout = jiffies + 
>> >> msecs_to_jiffies(500);
>> >> +   u32 status, rint;
>> >> +
>> >> +   /* if using dma we wait for dma_req to clear */
>> >> +   if (host->using_dma) {
>> >> +   do {
>> >> +   status = mci_readl(host, STATUS);
>> >> +   if (!(status & SDMMC_STATUS_DMA_REQ))
>> >> +   break;
>> >> +   cpu_relax();
>> >> +   } while (time_before(jiffies, timeout));
>> >> +
>> >> +   if (status & SDMMC_STATUS_DMA_REQ)
>> >> +   dev_err(host->dev,
>> >> +   "%s: Timeout waiting for 
>> >> dma_req to "
>> >> +   "clear during reset", 
>> >> __func__);
>> >> +
>> >> +   /* when using DMA next we reset the fifo 
>> >> again */
>> >> +   dw_mci_ctrl_reset(host, 
>> >> SDMMC_CTRL_FIFO_RESET);
>> >> +   }
>> >> +   /*
>> >> +* In all cases we clear the RAWINTS register to 
>> >> clear any
>> >> +* interrupts.
>> >> +*/
>> >> +   rint = mci_readl(host, RINTSTS);
>> >> +   rint = rint & (~mci_readl(host, MINTSTS));
>> >> you use the "status or te

Re: [PATCH] pwm: samsung: do not set manual update bit in pwm_samsung_config

[Tomasz Figa]

Hi Ajay,

On 12.05.2014 16:56, Ajay Kumar wrote:
> pwm_samsung_config sets manual update bit via call to
> pwm_samsung_enable even when the channel is already running.
> This causes noticable flickers on display if we try to change
> the backlight value from 0 to MAX, continiously.
> 
> So, we remove the call to pwm_samsung_enable from
> pwm_samsung_config to avoid the flicker and this change doesn't
> harm normal working since the pwm_bl core already takes care of
> calling pwm_samsung_enable whenever needed.
> 
> Signed-off-by: Ajay Kumar 
> ---
>  drivers/pwm/pwm-samsung.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
> index d66529a..ba6b650 100644
> --- a/drivers/pwm/pwm-samsung.c
> +++ b/drivers/pwm/pwm-samsung.c
> @@ -335,9 +335,6 @@ static int pwm_samsung_config(struct pwm_chip *chip, 
> struct pwm_device *pwm,
>   writel(tcnt, our_chip->base + REG_TCNTB(pwm->hwpwm));
>   writel(tcmp, our_chip->base + REG_TCMPB(pwm->hwpwm));
>  
> - if (test_bit(PWMF_ENABLED, &pwm->flags))
> - pwm_samsung_enable(chip, pwm);
> -
>   chan->period_ns = period_ns;
>   chan->tin_ns = tin_ns;
>   chan->duty_ns = duty_ns;
> 

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz
--
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 5/6] usb: host: ehci-tegra: Use devm_ioremap_resource instead of devm_ioremap

[Stephen Warren]

On 05/10/2014 06:00 AM, Vivek Gautam wrote:
> Using devm_ioremap_resource() API should actually be preferred over
> devm_ioremap(), since the former request the mem region first and then
> gives back the ioremap'ed memory pointer.
> devm_ioremap_resource() calls request_mem_region(), therby preventing
> other drivers to make any overlapping call to the same region.

This patch on its own works OK on Tegra. However, if a similar patch
were to be applied to the Tegra PHY driver, then I expect that would
break USB on Tegra. The reason is that the Tegra USB controller and PHY
registers are interleaved a bit randomly within the same address range,
and rather than call out which individual addresses are relevant to the
controller and the PHY, the DT for both devices just specifies the same
whole range, and the drivers only touch the appropriate registers within
the range. Perhaps we should have described that as an MFD rather than
separate DT nodes and devices, but that's not what we ended up with.
--
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 V2 0/3] drm/bridge: panel and chaining

[Sean Paul]

On Mon, May 12, 2014 at 3:06 AM, Andrzej Hajda  wrote:
> On 05/09/2014 05:05 PM, Ajay kumar wrote:
>> On Fri, May 9, 2014 at 7:29 PM, Rob Clark  wrote:
>>> On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda  wrote:
 On 05/08/2014 08:24 PM, Rob Clark wrote:
> On Thu, May 8, 2014 at 2:41 AM, Andrzej Hajda  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_conne

Re: [PATCH V5 18/20] ARM: exynos: cpuidle: Pass the AFTR callback to the platform_data

[Daniel Lezcano]

On 05/09/2014 02:02 PM, Tomasz Figa wrote:

Hi Arnd,

On 09.05.2014 12:56, Arnd Bergmann wrote:

On Friday 11 April 2014, Daniel Lezcano wrote:

No more dependency on the arch code. The platform_data field is used to set the
PM callback as the other cpuidle drivers.

Signed-off-by: Daniel Lezcano 
Reviewed-by: Viresh Kumar 
Reviewed-by: Bartlomiej Zolnierkiewicz 


This has just shown up in linux-next and broken randconfig builds.


diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index fe8dac8..d22f0e4 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -221,8 +221,9 @@ void exynos_restart(enum reboot_mode mode, const char *cmd)
  }

  static struct platform_device exynos_cpuidle = {
-   .name   = "exynos_cpuidle",
-   .id = -1,
+   .name  = "exynos_cpuidle",
+   .dev.platform_data = exynos_enter_aftr,
+   .id= -1,
  };



This is wrong on many levels, can we please do this properly?

* The exynos_enter_aftr function is compiled conditionally, so you can't just
   reference it from generic code, or you get a link error.


+1


That is true but still we have a link error without this patch. We 
shouldn't register and declare this structure if CONFIG_PM / 
CONFIG_CPU_IDLE are not set.



* 'static struct platform_device ...' has been deprecated for at least a decade,
   stop doing that. For any platform devices that get registered, there is
   platform_device_register_simple().


+0.5

The missing 0.5 is because you can't pass platform data using
platform_device_register_simple(). There is
platform_device_register_resndata(), though.


* There shouldn't need to be a platform_device to start with, this should all
   come from DT. We can't do this on arm64 anyway, so any code that may be
   shared between arm32 and arm64 should have proper abstractions.


-1

Exynos cpuidle is not a device on the SoC, so I don't think there is any
way to represent it in DT. The only thing I could see this is matching
root node with a central SoC driver that instantiates specific
subdevices, such as cpufreq and cpuidle, but I don't see any available
infrastructure for this.


There is a RFC for defining generic idle states [1].

The idea behind using the platform driver framework is to unify the code 
across the different drivers and separate the PM / cpuidle code.


By this way, we can move the different drivers to drivers/cpuidle and 
store them in a single place. That make easier the tracking, the review 
and the maintenance.


I am ok to by using platform_device_register_resndata() but I would 
prefer to do that a bit later by converting the other drivers too. That 
will be easier if we have them grouped in a single directory (this is 
what does this patchset at the end).


As there are some more work based on this patchset and the link error 
could be fixed as an independent patch, I would recommend to 
re-integrate it in the tree as asked by Bartlomiej.


Thanks
  -- Daniel


[1] http://www.spinics.net/lists/arm-kernel/msg328747.html


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] phy: exynos-mipi-video: fix check on array index

[Sylwester Nawrocki]

On 12/05/14 14:56, Antoine Ténart wrote:
> The phys array is of size EXYNOS_MIPI_PHYS_NUM. Trying to access the
> index EXYNOS_MIPI_PHYS_NUM should return an error.
> 
> Fixes: 069d2e26e9d6 "phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs"
> 
> Signed-off-by: Antoine Ténart 

Thanks for the fix,

Acked-by: Sylwester Nawrocki 

> ---
>  drivers/phy/phy-exynos-mipi-video.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/phy-exynos-mipi-video.c 
> b/drivers/phy/phy-exynos-mipi-video.c
> index 7f139326a642..ff026689358c 100644
> --- a/drivers/phy/phy-exynos-mipi-video.c
> +++ b/drivers/phy/phy-exynos-mipi-video.c
> @@ -101,7 +101,7 @@ static struct phy *exynos_mipi_video_phy_xlate(struct 
> device *dev,
>  {
>   struct exynos_mipi_video_phy *state = dev_get_drvdata(dev);
>  
> - if (WARN_ON(args->args[0] > EXYNOS_MIPI_PHYS_NUM))
> + if (WARN_ON(args->args[0] >= EXYNOS_MIPI_PHYS_NUM))
>   return ERR_PTR(-ENODEV);
>  
>   return state->phys[args->args[0]].phy;
--
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] pwm: samsung: do not set manual update bit in pwm_samsung_config

[Ajay kumar]

This is a simpler version of https://patchwork.kernel.org/patch/3113001/

On Mon, May 12, 2014 at 8:26 PM, Ajay Kumar  wrote:
> pwm_samsung_config sets manual update bit via call to
> pwm_samsung_enable even when the channel is already running.
> This causes noticable flickers on display if we try to change
> the backlight value from 0 to MAX, continiously.
>
> So, we remove the call to pwm_samsung_enable from
> pwm_samsung_config to avoid the flicker and this change doesn't
> harm normal working since the pwm_bl core already takes care of
> calling pwm_samsung_enable whenever needed.
>
> Signed-off-by: Ajay Kumar 
> ---
>  drivers/pwm/pwm-samsung.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
> index d66529a..ba6b650 100644
> --- a/drivers/pwm/pwm-samsung.c
> +++ b/drivers/pwm/pwm-samsung.c
> @@ -335,9 +335,6 @@ static int pwm_samsung_config(struct pwm_chip *chip, 
> struct pwm_device *pwm,
> writel(tcnt, our_chip->base + REG_TCNTB(pwm->hwpwm));
> writel(tcmp, our_chip->base + REG_TCMPB(pwm->hwpwm));
>
> -   if (test_bit(PWMF_ENABLED, &pwm->flags))
> -   pwm_samsung_enable(chip, pwm);
> -
> chan->period_ns = period_ns;
> chan->tin_ns = tin_ns;
> chan->duty_ns = duty_ns;
> --
> 1.8.3.2
>
--
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] pwm: samsung: do not set manual update bit in pwm_samsung_config

[Ajay Kumar]

pwm_samsung_config sets manual update bit via call to
pwm_samsung_enable even when the channel is already running.
This causes noticable flickers on display if we try to change
the backlight value from 0 to MAX, continiously.

So, we remove the call to pwm_samsung_enable from
pwm_samsung_config to avoid the flicker and this change doesn't
harm normal working since the pwm_bl core already takes care of
calling pwm_samsung_enable whenever needed.

Signed-off-by: Ajay Kumar 
---
 drivers/pwm/pwm-samsung.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index d66529a..ba6b650 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -335,9 +335,6 @@ static int pwm_samsung_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
writel(tcnt, our_chip->base + REG_TCNTB(pwm->hwpwm));
writel(tcmp, our_chip->base + REG_TCMPB(pwm->hwpwm));
 
-   if (test_bit(PWMF_ENABLED, &pwm->flags))
-   pwm_samsung_enable(chip, pwm);
-
chan->period_ns = period_ns;
chan->tin_ns = tin_ns;
chan->duty_ns = duty_ns;
-- 
1.8.3.2

--
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 0/6] usb: host: Cleanup for ioremap'ing hcd memory

[Alan Stern]

On Sat, 10 May 2014, Vivek Gautam wrote:

> Based on 'usb-next' branch of Greg's usb tree.
> 
> devm_ioremap_resource() API is advantageous over devm_ioremap()
> and should therefore be preferred to request any ioremap'ed address
> for hcd.
> 
> Changes from v1:
>  - Changed the way returned pointer is checked for error value
>as pointed out in the review comment in the mailing list.
> 
> Vivek Gautam (6):
>   usb: host: ehci-exynos: Use devm_ioremap_resource instead of
> devm_ioremap
>   usb: host: ehci-msm: Use devm_ioremap_resource instead of
> devm_ioremap
>   usb: host: ehci-mv: Use devm_ioremap_resource instead of devm_ioremap
>   usb: host: ehci-spear: Use devm_ioremap_resource instead of
> devm_ioremap
>   usb: host: ehci-tegra: Use devm_ioremap_resource instead of
> devm_ioremap
>   usb: host: ohci-exynos: Use devm_ioremap_resource instead of
> devm_ioremap
> 
>  drivers/usb/host/ehci-exynos.c |7 +++
>  drivers/usb/host/ehci-msm.c|7 +++
>  drivers/usb/host/ehci-mv.c |   16 ++--
>  drivers/usb/host/ehci-spear.c  |   13 +++--
>  drivers/usb/host/ehci-tegra.c  |7 +++
>  drivers/usb/host/ohci-exynos.c |7 +++
>  6 files changed, 21 insertions(+), 36 deletions(-)

For all six patches,

Acked-by: Alan Stern 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] clk: exynos5250: Add missing sysmmu clocks for DISP and ISP blocks

[Shaik Ameer Basha]

From: Cho KyongHo 

This patch adds the missing sysmmu clocks for Display and
ISP blocks.

Signed-off-by: Cho KyongHo 
Signed-off-by: Shaik Ameer Basha 
---
 drivers/clk/samsung/clk-exynos5250.c   |   35 
 include/dt-bindings/clock/exynos5250.h |   16 +++
 2 files changed, 51 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index 65cb966..3bc8f40 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -28,6 +28,8 @@
 #define MPLL_CON0  0x4100
 #define SRC_CORE1  0x4204
 #define GATE_IP_ACP0x8800
+#define GATE_IP_ISP0   0xc800
+#define GATE_IP_ISP1   0xc804
 #define CPLL_LOCK  0x10020
 #define EPLL_LOCK  0x10030
 #define VPLL_LOCK  0x10040
@@ -145,6 +147,8 @@ static unsigned long exynos5250_clk_regs[] __initdata = {
PLL_DIV2_SEL,
GATE_IP_DISP1,
GATE_IP_ACP,
+   GATE_IP_ISP0,
+   GATE_IP_ISP1,
 };
 
 static int exynos5250_clk_suspend(void)
@@ -202,6 +206,7 @@ PNAME(mout_aclk400_p)   = { "mout_aclk400_g3d_mid", 
"mout_gpll" };
 PNAME(mout_aclk200_sub_p) = { "fin_pll", "div_aclk200" };
 PNAME(mout_aclk266_sub_p) = { "fin_pll", "div_aclk266" };
 PNAME(mout_aclk333_sub_p) = { "fin_pll", "div_aclk333" };
+PNAME(mout_aclk400_isp_sub_p) = { "fin_pll", "div_aclk400_isp" };
 PNAME(mout_hdmi_p) = { "div_hdmi_pixel", "sclk_hdmiphy" };
 PNAME(mout_usb3_p) = { "mout_mpll_user", "mout_cpll" };
 PNAME(mout_group1_p)   = { "fin_pll", "fin_pll", "sclk_hdmi27m",
@@ -281,6 +286,7 @@ static struct samsung_mux_clock exynos5250_mux_clks[] 
__initdata = {
MUX(0, "mout_aclk333", mout_aclk166_p, SRC_TOP0, 16, 1),
MUX(0, "mout_aclk400_g3d_mid", mout_aclk200_p, SRC_TOP0, 20, 1),
 
+   MUX(0, "mout_aclk400_isp", mout_aclk200_p, SRC_TOP1, 24, 1),
MUX(0, "mout_aclk400_g3d", mout_aclk400_p, SRC_TOP1, 28, 1),
 
MUX(0, "mout_cpll", mout_cpll_p, SRC_TOP2, 8, 1),
@@ -292,6 +298,9 @@ static struct samsung_mux_clock exynos5250_mux_clks[] 
__initdata = {
 
MUX(0, "mout_aclk200_disp1_sub", mout_aclk200_sub_p, SRC_TOP3, 4, 1),
MUX(0, "mout_aclk266_gscl_sub", mout_aclk266_sub_p, SRC_TOP3, 8, 1),
+   MUX(0, "mout_aclk_266_isp_sub", mout_aclk266_sub_p, SRC_TOP3, 16, 1),
+   MUX(0, "mout_aclk_400_isp_sub", mout_aclk400_isp_sub_p,
+   SRC_TOP3, 20, 1),
MUX(0, "mout_aclk333_sub", mout_aclk333_sub_p, SRC_TOP3, 24, 1),
 
MUX(0, "mout_cam_bayer", mout_group1_p, SRC_GSCL, 12, 4),
@@ -364,6 +373,7 @@ static struct samsung_div_clock exynos5250_div_clks[] 
__initdata = {
DIV(0, "div_aclk400_g3d", "mout_aclk400_g3d", DIV_TOP0,
24, 3),
 
+   DIV(0, "div_aclk400_isp", "mout_aclk400_isp", DIV_TOP1, 20, 3),
DIV(0, "div_aclk66_pre", "mout_mpll_user", DIV_TOP1, 24, 3),
 
DIV(0, "div_cam_bayer", "mout_cam_bayer", DIV_GSCL, 12, 4),
@@ -629,6 +639,31 @@ static struct samsung_gate_clock exynos5250_gate_clks[] 
__initdata = {
GATE(CLK_WDT, "wdt", "div_aclk66", GATE_IP_PERIS, 19, 0, 0),
GATE(CLK_RTC, "rtc", "div_aclk66", GATE_IP_PERIS, 20, 0, 0),
GATE(CLK_TMU, "tmu", "div_aclk66", GATE_IP_PERIS, 21, 0, 0),
+   GATE(CLK_SMMU_TV, "smmu_tv", "mout_aclk200_disp1_sub",
+   GATE_IP_DISP1, 2, 0, 0),
+   GATE(CLK_SMMU_FIMD1, "smmu_fimd1", "mout_aclk200_disp1_sub",
+   GATE_IP_DISP1, 8, 0, 0),
+   GATE(CLK_SMMU_2D, "smmu_2d", "div_aclk200", GATE_IP_ACP, 7, 0, 0),
+   GATE(CLK_SMMU_FIMC_ISP, "smmu_fimc_isp", "mout_aclk_266_isp_sub",
+   GATE_IP_ISP0, 8, 0, 0),
+   GATE(CLK_SMMU_FIMC_DRC, "smmu_fimc_drc", "mout_aclk_266_isp_sub",
+   GATE_IP_ISP0, 9, 0, 0),
+   GATE(CLK_SMMU_FIMC_FD, "smmu_fimc_fd", "mout_aclk_266_isp_sub",
+   GATE_IP_ISP0, 10, 0, 0),
+   GATE(CLK_SMMU_FIMC_SCC, "smmu_fimc_scc", "mout_aclk_266_isp_sub",
+   GATE_IP_ISP0, 11, 0, 0),
+   GATE(CLK_SMMU_FIMC_SCP, "smmu_fimc_scp", "mout_aclk_266_isp_sub",
+   GATE_IP_ISP0, 12, 0, 0),
+   GATE(CLK_SMMU_FIMC_MCU, "smmu_fimc_mcu", "mout_aclk_400_isp_sub",
+   GATE_IP_ISP0, 13, 0, 0),
+   GATE(CLK_SMMU_FIMC_ODC, "smmu_fimc_odc", "mout_aclk_266_isp_sub",
+   GATE_IP_ISP1, 4, 0, 0),
+   GATE(CLK_SMMU_FIMC_DIS0, "smmu_fimc_dis0", "mout_aclk_266_isp_sub",
+   GATE_IP_ISP1, 5, 0, 0),
+   GATE(CLK_SMMU_FIMC_DIS1, "smmu_fimc_dis1", "mout_aclk_266_isp_sub",
+   GATE_IP_ISP1, 6, 0, 0),
+   GATE(CLK_SMMU_FIMC_3DNR, "smmu_fimc_3dnr", "mout_aclk_266_isp_sub",
+   GATE_IP_ISP1, 7, 0, 0),
 };
 
 static struct samsung_pll_rate_table vpll_24mhz_tbl[] __initdata = {
diff --git a/include/d

Re: [PATCH v8 1/2] phy: Add new Exynos5 USB 3.0 PHY driver

[Kishon Vijay Abraham I]

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.

Thanks
Kishon
> Signed-off-by: Vivek Gautam 
> ---
> 
> 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.
> 
> 
>  .../devicetree/bindings/phy/samsung-phy.txt|   47 ++
>  drivers/phy/Kconfig|   11 +
>  drivers/phy/Makefile   |1 +
>  drivers/phy/phy-exynos5-usbdrd.c   |  644 
> 
>  include/linux/mfd/syscon/exynos5-pmu.h |   44 ++
>  5 files changed, 747 insertions(+)
>  create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>  create mode 100644 include/linux/mfd/syscon/exynos5-pmu.h
> 
> 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;
> + };
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 4906c27..b70cc07 100644

[PATCH] phy: exynos-mipi-video: fix check on array index

[Antoine Ténart]

The phys array is of size EXYNOS_MIPI_PHYS_NUM. Trying to access the
index EXYNOS_MIPI_PHYS_NUM should return an error.

Fixes: 069d2e26e9d6 "phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs"

Signed-off-by: Antoine Ténart 
---
 drivers/phy/phy-exynos-mipi-video.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/phy-exynos-mipi-video.c 
b/drivers/phy/phy-exynos-mipi-video.c
index 7f139326a642..ff026689358c 100644
--- a/drivers/phy/phy-exynos-mipi-video.c
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -101,7 +101,7 @@ static struct phy *exynos_mipi_video_phy_xlate(struct 
device *dev,
 {
struct exynos_mipi_video_phy *state = dev_get_drvdata(dev);
 
-   if (WARN_ON(args->args[0] > EXYNOS_MIPI_PHYS_NUM))
+   if (WARN_ON(args->args[0] >= EXYNOS_MIPI_PHYS_NUM))
return ERR_PTR(-ENODEV);
 
return state->phys[args->args[0]].phy;
-- 
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: [RFC V2 0/3] drm/bridge: panel and chaining

[Rob Clark]

On Mon, May 12, 2014 at 3:06 AM, Andrzej Hajda  wrote:
> On 05/09/2014 05:05 PM, Ajay kumar wrote:
>> On Fri, May 9, 2014 at 7:29 PM, Rob Clark  wrote:
>>> On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda  wrote:
 On 05/08/2014 08:24 PM, Rob Clark wrote:
> On Thu, May 8, 2014 at 2:41 AM, Andrzej Hajda  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_conne

Re: [PATCH v3 1/2] [media] v4l: Add source change event

[Arun Kumar K]

Hi Hans, Laurent,

On 05/09/14 18:45, Hans Verkuil wrote:
> On 05/09/2014 03:09 PM, Laurent Pinchart wrote:
>> Hi Arun,
>>
>> Thank you for the patch. We're slowly getting there :-)
>>
>> On Thursday 08 May 2014 17:19:15 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/output port which
>>> it is interested in.
>>>
>>> Signed-off-by: Arun Kumar K 
>>> ---
>>>  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 @@
>>>
>>>  
>>>
>>> +
>>> +  struct v4l2_event_src_change
>>> +  
>>> +   &cs-str;
>>> +   
>>> + 
>>> +   __u32
>>> +   changes
>>> +   
>>> + A bitmask that tells what has changed. See >> linkend="src-changes-flags" />. +   
>>> + 
>>> +   
>>> +  
>>> +
>>> +
>>>  
>>>Changes
>>>
>>> @@ -270,6 +286,22 @@
>>> 
>>>
>>>  
>>> +
>>> +
>>> +  Source Changes
>>> +  
>>> +   &cs-def;
>>> +   
>>> + 
>>> +   V4L2_EVENT_SRC_CH_RESOLUTION
>>> +   0x0001
>>> +   This event gets triggered when a resolution change is
>>> +   detected at runtime. This can typically come from a video decoder.
>>> +   
>>> + 
>>> +   
>>> +  
>>> +
>>>
>>>
>>>  &return-value;
>>> diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>>> b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index
>>> 5c70b61..8012829 100644
>>> --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>>> +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>>> @@ -155,6 +155,25 @@
>>> 
>>>   
>>>   
>>> +   V4L2_EVENT_SOURCE_CHANGE
>>> +   5
>>> +   
>>> + This event is triggered when a format 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 id
>>> +   matches the pad/input/output index from which you want to
>>> +  receive events.
>>> +
>>> +  This event has a &v4l2-event-source-change; associated
>>> + with it. The changes 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.
>>> +   
>>> + 
>>> + 
>>> V4L2_EVENT_PRIVATE_START
>>> 0x0800
>>> Base event number for driver-private events.
>>> 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,
>>> +   const struct v4l2_event_subscription *sub)
>>> +{
>>> +   if (sub->type == V4L2_EVENT_SOURCE_CHANGE)
>>> +

Re: [PATCH v3 0/5] ARM: dts: enable hdmi for exynos5 based peach and snow boards

[Rahul Sharma]

On 12 May 2014 15:54, Rahul Sharma  wrote:
> From: Rahul Sharma 
>
> Enable hdmi for exynos5250 based snow board and exynos5420
> based peach pit board. It also adds properties to hdmi nodes
> for accessing hdmiphy as simple phys.
>
> 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) Arun's patch for adding peach-pit board dts file at
> http://www.spinics.net/lists/linux-samsung-soc/msg30103.html. [Patch is 
> 'ACK'ed.]
> 2) Sachin's patch for snow board dts file at
> https://patches.linaro.org/28325/
> 3) DRM Hdmi driver patch which is changing the DT binding at
> http://www.spinics.net/lists/linux-samsung-soc/msg28052.html
> 4) Arun's patches for basic Exynos5800 support, available at
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/30667
> [Already Applied in Kukjin's v3.16-next/soc-exynos]
>

Updating the dependency:
1) Sachin's patch for snow board dts file at
   https://patches.linaro.org/28325/
2) DRM Hdmi driver patch which is changing the DT binding at
   http://www.spinics.net/lists/linux-samsung-soc/msg28052.html

All other patches are already Applied in Kukjin's for-next and
v3.16-next/soc-exynos branches.

> 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 |   26 
> +
>  8 files changed, 77 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

Re: [PATCH v3 5/5] ARM: dts: enable hdmi for exynos5800 based peach-pi board

[Rahul Sharma]

On 12 May 2014 16:22, Arun Kumar K  wrote:
> Hi Rahul,
>
> On 05/12/14 15:54, Rahul Sharma wrote:
>> From: Rahul Sharma 
>>
>> Enable hdmi for peach-pi board.
>>
>> Signed-off-by: Rahul Sharma 
>> ---
>>  arch/arm/boot/dts/exynos5800-peach-pi.dts |   26 ++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
>> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> index 742655b..bbb445a 100644
>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> @@ -72,6 +72,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>;
>> + };
>
> This node is already added in 5420-pinctrl.dtsi in patch 3/5.
> You can drop it from here.
>

yea correct. I will remove this pin.

Regards,
Rahul Sharma.

> Regards
> Arun
>
>>  };
>>
>>  &rtc {
>> @@ -134,6 +141,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
>>
--
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 5/5] ARM: dts: enable hdmi for exynos5800 based peach-pi board

[Arun Kumar K]

Hi Rahul,

On 05/12/14 15:54, Rahul Sharma wrote:
> From: Rahul Sharma 
> 
> Enable hdmi for peach-pi board.
> 
> Signed-off-by: Rahul Sharma 
> ---
>  arch/arm/boot/dts/exynos5800-peach-pi.dts |   26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index 742655b..bbb445a 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -72,6 +72,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>;
> + };

This node is already added in 5420-pinctrl.dtsi in patch 3/5.
You can drop it from here.

Regards
Arun

>  };
>  
>  &rtc {
> @@ -134,6 +141,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
> 
--
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 5/5] ARM: dts: enable hdmi for exynos5800 based peach-pi board

[Rahul Sharma]

From: Rahul Sharma 

Enable hdmi for peach-pi board.

Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/exynos5800-peach-pi.dts |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 742655b..bbb445a 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -72,6 +72,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>;
+   };
 };
 
 &rtc {
@@ -134,6 +141,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 v3 2/5] ARM: dts: change to correct compatible string for exynos5420 hdmi

[Rahul Sharma]

From: Rahul Sharma 

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 
---
 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 v3 0/5] ARM: dts: enable hdmi for exynos5 based peach and snow boards

[Rahul Sharma]

From: Rahul Sharma 

Enable hdmi for exynos5250 based snow board and exynos5420
based peach pit board. It also adds properties to hdmi nodes
for accessing hdmiphy as simple phys.

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) Arun's patch for adding peach-pit board dts file at
http://www.spinics.net/lists/linux-samsung-soc/msg30103.html. [Patch is 
'ACK'ed.]
2) Sachin's patch for snow board dts file at
https://patches.linaro.org/28325/
3) DRM Hdmi driver patch which is changing the DT binding at
http://www.spinics.net/lists/linux-samsung-soc/msg28052.html
4) Arun's patches for basic Exynos5800 support, available at
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/30667
[Already Applied in Kukjin's v3.16-next/soc-exynos]

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 |   26 +
 8 files changed, 77 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 v3 1/5] ARM: dts: enable hdmi for exynos5250 based snow board

[Rahul Sharma]

From: Rahul Sharma 

Enable support for HDMI for exynos5250 based Snow board.

Signed-off-by: Rahul Sharma 
---
 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 v3 3/5] ARM: dts: enable hdmi for exynos5420 based peach-pit board

[Rahul Sharma]

From: Rahul Sharma 

Enable hdmi for exynos5420 based peach-pit board.

Signed-off-by: Rahul Sharma 
---
 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 v3 4/5] ARM: dts: remove chip specific hdmi hpd pin from board

[Rahul Sharma]

From: Rahul Sharma 

"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 
---
 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

[PATCH v2] [media] s5p-mfc: Don't try to resubmit VP8 bitstream buffer for decode.

[Arun Kumar K]

From: Pawel Osciak 

Currently, for formats that are not H264, MFC driver will check
the consumed stream size returned by the firmware and, based on that,
will try to decide whether the bitstream buffer contained more than
one frame. If the size of the buffer is larger than the consumed
stream, it assumes that there are more frames in the buffer and that the
buffer should be resubmitted for decode. This rarely works though and
actually introduces problems, because:

- v7 firmware will always return consumed stream size equal to whatever
the driver passed to it when running decode (which is the size of the whole
buffer), which means we will never try to resubmit, because the firmware
will always tell us that it consumed all the data we passed to it;

- v6 firmware will return the number of consumed bytes, but will not
include the padding ("stuffing") bytes that are allowed after the frame
in VP8. Since there is no way of figuring out how many of those bytes
follow the frame without getting the frame size from IVF headers (or
somewhere else, but not from the stream itself), the driver tries to guess that
padding size is not larger than 4 bytes, which is not always true;

The only way to make it work is to queue only one frame per buffer from
userspace and the check in the kernel is useless and wrong for VP8.
So adding VP8 also along with H264 to disallow re-submitting of buffer
back to hardware for decode.

Signed-off-by: Pawel Osciak 
Signed-off-by: Arun Kumar K 
---
Changes from v1
- Made the condition to specifically add VP8 case only
  suggested by Kamil.
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 0f796ad..2d7d1ae 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -382,6 +382,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
ctx->consumed_stream += s5p_mfc_hw_call(dev->mfc_ops,
get_consumed_stream, dev);
if (ctx->codec_mode != S5P_MFC_CODEC_H264_DEC &&
+   ctx->codec_mode != S5P_MFC_CODEC_VP8_DEC &&
ctx->consumed_stream + STUFF_BYTE <
src_buf->b->v4l2_planes[0].bytesused) {
/* Run MFC again on the same buffer */
-- 
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 v13 00/19] iommu/exynos: Fixes and Enhancements of System MMU driver with DT

[Arnd Bergmann]

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.

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

[RESEND PATCH v6 7/7] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2

[Jungseok Lee]

This patch adds 4 levels of translation tables implementation for both
HYP and stage2.

Both symmetric and asymmetric configurations for page size and translation
levels are are validated on Fast Models:

 1) 4KB  + 3 levels guest on 4KB  + 4 levels host
 2) 4KB  + 4 levels guest on 4KB  + 4 levels host
 3) 64KB + 2 levels guest on 4KB  + 4 levels host
 4) 4KB  + 3 levels guest on 64KB + 2 levels host
 5) 4KB  + 4 levels guest on 64KB + 2 levels host
 6) 64KB + 2 levels guest on 64KB + 2 levels host

Cc: Marc Zyngier 
Cc: Christoffer Dall 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
Acked-by: Kukjin Kim 
---
Please ignore the previous patch since it has a critical error
on KVM_MMU_CACHE_MIN_PAGES.

I'm really sorry about noise. My email client terminated unexpectedly,
so some words are dropped :(
---
 arch/arm/include/asm/kvm_mmu.h   |   10 +
 arch/arm/kvm/arm.c   |8 
 arch/arm/kvm/mmu.c   |   77 --
 arch/arm64/include/asm/kvm_arm.h |   12 ++
 arch/arm64/include/asm/kvm_mmu.h |   12 ++
 5 files changed, 108 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 5c7aa3c..d319ef6 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -37,6 +37,11 @@
  */
 #define TRAMPOLINE_VA  UL(CONFIG_VECTORS_BASE)
 
+/*
+ * KVM_MMU_CACHE_MIN_PAGES is the number of stage2 page table translation 
levels.
+ */
+#define KVM_MMU_CACHE_MIN_PAGES2
+
 #ifndef __ASSEMBLY__
 
 #include 
@@ -94,6 +99,11 @@ static inline void kvm_clean_pgd(pgd_t *pgd)
clean_dcache_area(pgd, PTRS_PER_S2_PGD * sizeof(pgd_t));
 }
 
+static inline void kvm_clean_pmd(pmd_t *pmd)
+{
+   clean_dcache_area(pmd, PTRS_PER_PMD * sizeof(pmd_t));
+}
+
 static inline void kvm_clean_pmd_entry(pmd_t *pmd)
 {
clean_pmd_entry(pmd);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 9f19f2c..0785291 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -473,11 +473,19 @@ static int set_vttbr_baddr_mask(void)
 * 21 <= T0SZ <= 30 is valid under 3 level of translation tables
 * 30 <= T0SZ <= 39 is valid under 2 level of translation tables
 */
+#ifdef CONFIG_ARM64_3_LEVELS
if (t0sz <= 20) {
kvm_err("Cannot support %d-bit address space\n", 64 - t0sz);
return -EINVAL;
}
vttbr_x = 37 - t0sz;
+#else
+   if (t0sz <= 15) {
+   kvm_err("Cannot support %d-bit address space\n", 64 - t0sz);
+   return -EINVAL;
+   }
+   vttbr_x = 28 - t0sz;
+#endif
 #endif
vttbr_baddr_mask = (((1LLU << (48 - vttbr_x)) - 1) << (vttbr_x - 1));
 #endif
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 16f8049..6e2a0b0 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -390,13 +390,44 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned 
long start,
return 0;
 }
 
+static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
+  unsigned long end, unsigned long pfn,
+  pgprot_t prot)
+{
+   pud_t *pud;
+   pmd_t *pmd;
+   unsigned long addr, next;
+
+   addr = start;
+   do {
+   pud = pud_offset(pgd, addr);
+
+   if (pud_none_or_clear_bad(pud)) {
+   pmd = pmd_alloc_one(NULL, addr);
+   if (!pmd) {
+   kvm_err("Cannot allocate Hyp pmd\n");
+   return -ENOMEM;
+   }
+   pud_populate(NULL, pud, pmd);
+   get_page(virt_to_page(pud));
+   kvm_flush_dcache_to_poc(pud, sizeof(*pud));
+   }
+
+   next = pud_addr_end(addr, end);
+
+   create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
+   pfn += (next - addr) >> PAGE_SHIFT;
+   } while (addr = next, addr != end);
+
+   return 0;
+}
+
 static int __create_hyp_mappings(pgd_t *pgdp,
 unsigned long start, unsigned long end,
 unsigned long pfn, pgprot_t prot)
 {
pgd_t *pgd;
pud_t *pud;
-   pmd_t *pmd;
unsigned long addr, next;
int err = 0;
 
@@ -405,22 +436,21 @@ static int __create_hyp_mappings(pgd_t *pgdp,
end = PAGE_ALIGN(end);
do {
pgd = pgdp + pgd_index(addr);
-   pud = pud_offset(pgd, addr);
 
-   if (pud_none_or_clear_bad(pud)) {
-   pmd = pmd_alloc_one(NULL, addr);
-   if (!pmd) {
-   kvm_err("Cannot allocate Hyp pmd\n");
+   if (pgd_none(*pgd)) {
+   pud = pud_alloc_one(NULL, addr);
+   if (!pud) {
+   kvm_err("Cannot allocate Hyp pud

[RESEND PATCH v6 7/7] arm64: KVM: Implement 4 levels of translation tables for

[Jungseok Lee]

This patch adds 4 levels of translation tables implementation for both
HYP and stage2.

Both symmetric and asymmetric configurations for page size and translation
levels are are validated on Fast Models:

 1) 4KB  + 3 levels guest on 4KB  + 4 levels host
 2) 4KB  + 4 levels guest on 4KB  + 4 levels host
 3) 64KB + 2 levels guest on 4KB  + 4 levels host
 4) 4KB  + 3 levels guest on 64KB + 2 levels host
 5) 4KB  + 4 levels guest on 64KB + 2 levels host
 6) 64KB + 2 levels guest on 64KB + 2 levels host

Cc: Marc Zyngier 
Cc: Christoffer Dall 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
Please ignore the previous patch since it has a critical error
on KVM_MMU_CACHE_MIN_PAGES.
---
 arch/arm/include/asm/kvm_mmu.h   |   10 +
 arch/arm/kvm/arm.c   |8 
 arch/arm/kvm/mmu.c   |   77 --
 arch/arm64/include/asm/kvm_arm.h |   12 ++
 arch/arm64/include/asm/kvm_mmu.h |   12 ++
 5 files changed, 108 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 5c7aa3c..36b9835 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -37,6 +37,11 @@
  */
 #define TRAMPOLINE_VA  UL(CONFIG_VECTORS_BASE)
 
+/*
+ * KVM_MMU_CACHE_MIN_PAGES is the number of stage2 page table translation 
levels.
+ */
+#define KVM_MMU_CACHE_MIN_PAGES2
+
 #ifndef __ASSEMBLY__
 
 #include 
@@ -94,6 +99,11 @@ static inline void kvm_clean_pgd(pgd_t *pgd)
clean_dcache_area(pgd, PTRS_PER_S2_PGD * sizeof(pgd_t));
 }
 
+static inline void kvm_clean_pmd(pmd_t *pmd)
+{
+   clean_dcache_area(pmd, PTRS_PER_PMD * sizeof(pmd_t));
+}
+
 static inline void kvm_clean_pmd_entry(pmd_t *pmd)
 {
clean_pmd_entry(pmd);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 9f19f2c..0785291 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -473,11 +473,19 @@ static int set_vttbr_baddr_mask(void)
 * 21 <= T0SZ <= 30 is valid under 3 level of translation tables
 * 30 <= T0SZ <= 39 is valid under 2 level of translation tables
 */
+#ifdef CONFIG_ARM64_3_LEVELS
if (t0sz <= 20) {
kvm_err("Cannot support %d-bit address space\n", 64 - t0sz);
return -EINVAL;
}
vttbr_x = 37 - t0sz;
+#else
+   if (t0sz <= 15) {
+   kvm_err("Cannot support %d-bit address space\n", 64 - t0sz);
+   return -EINVAL;
+   }
+   vttbr_x = 28 - t0sz;
+#endif
 #endif
vttbr_baddr_mask = (((1LLU << (48 - vttbr_x)) - 1) << (vttbr_x - 1));
 #endif
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 16f8049..6e2a0b0 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -390,13 +390,44 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned 
long start,
return 0;
 }
 
+static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
+  unsigned long end, unsigned long pfn,
+  pgprot_t prot)
+{
+   pud_t *pud;
+   pmd_t *pmd;
+   unsigned long addr, next;
+
+   addr = start;
+   do {
+   pud = pud_offset(pgd, addr);
+
+   if (pud_none_or_clear_bad(pud)) {
+   pmd = pmd_alloc_one(NULL, addr);
+   if (!pmd) {
+   kvm_err("Cannot allocate Hyp pmd\n");
+   return -ENOMEM;
+   }
+   pud_populate(NULL, pud, pmd);
+   get_page(virt_to_page(pud));
+   kvm_flush_dcache_to_poc(pud, sizeof(*pud));
+   }
+
+   next = pud_addr_end(addr, end);
+
+   create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
+   pfn += (next - addr) >> PAGE_SHIFT;
+   } while (addr = next, addr != end);
+
+   return 0;
+}
+
 static int __create_hyp_mappings(pgd_t *pgdp,
 unsigned long start, unsigned long end,
 unsigned long pfn, pgprot_t prot)
 {
pgd_t *pgd;
pud_t *pud;
-   pmd_t *pmd;
unsigned long addr, next;
int err = 0;
 
@@ -405,22 +436,21 @@ static int __create_hyp_mappings(pgd_t *pgdp,
end = PAGE_ALIGN(end);
do {
pgd = pgdp + pgd_index(addr);
-   pud = pud_offset(pgd, addr);
 
-   if (pud_none_or_clear_bad(pud)) {
-   pmd = pmd_alloc_one(NULL, addr);
-   if (!pmd) {
-   kvm_err("Cannot allocate Hyp pmd\n");
+   if (pgd_none(*pgd)) {
+   pud = pud_alloc_one(NULL, addr);
+   if (!pud) {
+   kvm_err("Cannot allocate Hyp pud\n");
err = -ENOMEM;
goto out;
}
- 

Re: [PATCH 0/4] Introducing Exynos ChipId driver

[Arnd Bergmann]

On Sunday 11 May 2014 18:47:28 Olof Johansson wrote:
> > > Also for platsmp.c and pm.c I can think of following approaches
> > > 1: Keep these macros till we get generic solution?
> > > 2: Allow chipid driver to expose APIs to check SoC id and SoC revisions 
> > > till we get
> > > generic solution. So that at least we can remove #ifdef  based macros
> > > as soc_is_exynosXYZ.
> > > 3: Use of "of_flat_dt_is_compatible" or similar APIs in these machine 
> > > files 
> > > till we get
> > > generic solution. For some cases where we want to know SoC revision let us
> > > map chipid register and get revision there itself.
> > > 
> > > Please let me know what approach you think will be good?
> > 
> > I think 1 or 2 would be better than 3. Between those two, I'm undecided,
> > but I think either way the SoC specific values would be better kept in the
> > mach-samsung directory than in plat/cpu.h or linux/exynos-chipid.h.
> 
> The generic solution is already there: of_machine_is_compatible() is perfectly
> sensible to use for _some_ of these inits. Cpufreq is one of the few that 
> comes
> to mind, and maybe some of the platsmp and pm stuff.
> 
> Note that none of them should be used in runtime, i.e. you should only use 
> them
> at probe/setup time and maybe have a local state in the driver if needed.
> 
> I'd rather get people used to that format than everybody needing to implement
> a chipid driver now too, especially on platforms that might not even have a
> suitable chipid block to base a driver around -- not to mention having to
> fill the namespace with is_soc_*() stuff.

I was coming from the other angle: exynos is already using soc_is_*() in too
many places. I'd like to first see the ones cleaned up that really should be
doing something else because they have a device-local ID to look at.

If we end up with a couple of instances that don't have a good alternative,
we can use of_machine_is_compatible() for those, but I'd like to avoid doing
a blind conversion because that would likely lead to more instances in the
future, not fewer.

I agree that we should have to introduce new chip ID drivers on other
platforms for the purpose of finding out the SoC version, especially not
with private APIs.

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 v6 6/7] arm64: KVM: Set physical address size related factors in runtime

[Jungseok Lee]

This patch sets TCR_EL2.PS, VTCR_EL2.T0SZ and vttbr_baddr_mask in runtime,
not compile time.

In ARMv8, EL2 physical address size (TCR_EL2.PS) and stage2 input address
size (VTCR_EL2.T0SZE) cannot be determined in compile time since they
depends on hardware capability.

According to Table D4-23 and Table D4-25 in ARM DDI 0487A.b document,
vttbr_x is calculated using different hard-coded values with consideration
of T0SZ, granule size and the level of translation tables. Therefore,
vttbr_baddr_mask should be determined dynamically.

Cc: Marc Zyngier 
Cc: Christoffer Dall 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 arch/arm/kvm/arm.c   |   82 +-
 arch/arm64/include/asm/kvm_arm.h |   17 ++--
 arch/arm64/kvm/hyp-init.S|   20 +++---
 3 files changed, 98 insertions(+), 21 deletions(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index f0e50a0..9f19f2c 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -61,6 +62,9 @@ static atomic64_t kvm_vmid_gen = ATOMIC64_INIT(1);
 static u8 kvm_next_vmid;
 static DEFINE_SPINLOCK(kvm_vmid_lock);
 
+/* VTTBR mask cannot be determined in complie time under ARMv8 */
+static u64 vttbr_baddr_mask;
+
 static bool vgic_present;
 
 static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu)
@@ -412,6 +416,75 @@ static bool need_new_vmid_gen(struct kvm *kvm)
 }
 
 /**
+ * set_vttbr_baddr_mask - set mask value for vttbr base address
+ *
+ * In ARMv8, vttbr_baddr_mask cannot be determined in compile time since stage2
+ * input address size depends on hardware capability. Thus, it is needed to 
read
+ * ID_AA64MMFR0_EL1.PARange first and then set vttbr_baddr_mask with 
consideration
+ * of both granule size and the level of translation tables.
+ */
+static int set_vttbr_baddr_mask(void)
+{
+#ifndef CONFIG_ARM64
+   vttbr_baddr_mask = VTTBR_BADDR_MASK;
+#else
+   int pa_range, t0sz, vttbr_x;
+
+   pa_range = read_cpuid(ID_AA64MMFR0_EL1) & 0xf;
+
+   switch (pa_range) {
+   case 0:
+   t0sz = VTCR_EL2_T0SZ(32);
+   break;
+   case 1:
+   t0sz = VTCR_EL2_T0SZ(36);
+   break;
+   case 2:
+   t0sz = VTCR_EL2_T0SZ(40);
+   break;
+   case 3:
+   t0sz = VTCR_EL2_T0SZ(42);
+   break;
+   case 4:
+   t0sz = VTCR_EL2_T0SZ(44);
+   break;
+   default:
+   t0sz = VTCR_EL2_T0SZ(48);
+   }
+
+   /*
+* See Table D4-23 and Table D4-25 in ARM DDI 0487A.b to figure out
+* the origin of the hardcoded values, 38 and 37.
+*/
+#ifdef CONFIG_ARM64_64K_PAGES
+   /*
+* 16 <= T0SZ <= 21 is valid under 3 level of translation tables
+* 18 <= T0SZ <= 34 is valid under 2 level of translation tables
+* 31 <= T0SZ <= 39 is valid under 1 level of transltaion tables
+*/
+   if (t0sz <= 17) {
+   kvm_err("Cannot support %d-bit address space\n", 64 - t0sz);
+   return -EINVAL;
+   }
+   vttbr_x = 38 - t0sz;
+#else
+   /*
+* 16 <= T0SZ <= 24 is valid under 4 level of translation tables
+* 21 <= T0SZ <= 30 is valid under 3 level of translation tables
+* 30 <= T0SZ <= 39 is valid under 2 level of translation tables
+*/
+   if (t0sz <= 20) {
+   kvm_err("Cannot support %d-bit address space\n", 64 - t0sz);
+   return -EINVAL;
+   }
+   vttbr_x = 37 - t0sz;
+#endif
+   vttbr_baddr_mask = (((1LLU << (48 - vttbr_x)) - 1) << (vttbr_x - 1));
+#endif
+   return 0;
+}
+
+/**
  * update_vttbr - Update the VTTBR with a valid VMID before the guest runs
  * @kvmThe guest that we are about to run
  *
@@ -465,7 +538,7 @@ static void update_vttbr(struct kvm *kvm)
/* update vttbr to be used with the new vmid */
pgd_phys = virt_to_phys(kvm->arch.pgd);
vmid = ((u64)(kvm->arch.vmid) << VTTBR_VMID_SHIFT) & VTTBR_VMID_MASK;
-   kvm->arch.vttbr = pgd_phys & VTTBR_BADDR_MASK;
+   kvm->arch.vttbr = pgd_phys & vttbr_baddr_mask;
kvm->arch.vttbr |= vmid;
 
spin_unlock(&kvm_vmid_lock);
@@ -1051,6 +1124,12 @@ int kvm_arch_init(void *opaque)
}
}
 
+   err = set_vttbr_baddr_mask();
+   if (err) {
+   kvm_err("Cannot set vttbr_baddr_mask\n");
+   return -EINVAL;
+   }
+
cpu_notifier_register_begin();
 
err = init_hyp_mode();
@@ -1068,6 +1147,7 @@ int kvm_arch_init(void *opaque)
hyp_cpu_pm_init();
 
kvm_coproc_table_init();
+
return 0;
 out_err:
cpu_notifier_register_done();
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 3d69030..8dbef70 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_ar

[PATCH v6 2/7] arm64: Introduce VA_BITS and translation level options

[Jungseok Lee]

This patch adds virtual address space size and a level of translation
tables to kernel configuration. It facilicates introduction of
different MMU options, such as 4KB + 4 levels, 16KB + 4 levels and
64KB + 3 levels, easily.

The idea is based on the discussion with Catalin Marinas:
http://www.spinics.net/linux/lists/arm-kernel/msg319552.html

Cc: Catalin Marinas 
Cc: Steve Capper 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
Acked-by: Kukjin Kim 
Reviewed-by: Christoffer Dall 
---
 arch/arm64/Kconfig |   45 +++-
 arch/arm64/include/asm/memory.h|6 +
 arch/arm64/include/asm/page.h  |2 +-
 arch/arm64/include/asm/pgalloc.h   |4 +--
 arch/arm64/include/asm/pgtable-hwdef.h |2 +-
 arch/arm64/include/asm/pgtable.h   |8 +++---
 arch/arm64/include/asm/tlb.h   |2 +-
 7 files changed, 54 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9a5b5fe..9a28cbe 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -144,14 +144,57 @@ endmenu
 
 menu "Kernel Features"
 
+choice
+   prompt "Page size"
+   default ARM64_4K_PAGES
+   help
+ Allows page size.
+
+config ARM64_4K_PAGES
+   bool "4KB"
+   help
+ This feature enables 4KB pages support.
+
 config ARM64_64K_PAGES
-   bool "Enable 64KB pages support"
+   bool "64KB"
help
  This feature enables 64KB pages support (4KB by default)
  allowing only two levels of page tables and faster TLB
  look-up. AArch32 emulation is not available when this feature
  is enabled.
 
+endchoice
+
+choice
+   prompt "Virtual address space size"
+   default ARM64_VA_BITS_39 if ARM64_4K_PAGES
+   default ARM64_VA_BITS_42 if ARM64_64K_PAGES
+   help
+ Allows choosing one of multiple possible virtual address
+ space sizes. The level of translation table is determined by
+ a combination of page size and virtual address space size.
+
+config ARM64_VA_BITS_39
+   bool "39-bit"
+   depends on ARM64_4K_PAGES
+
+config ARM64_VA_BITS_42
+   bool "42-bit"
+   depends on ARM64_64K_PAGES
+
+endchoice
+
+config ARM64_VA_BITS
+   int
+   default 39 if ARM64_VA_BITS_39
+   default 42 if ARM64_VA_BITS_42
+
+config ARM64_2_LEVELS
+   def_bool y if ARM64_64K_PAGES && ARM64_VA_BITS_42
+
+config ARM64_3_LEVELS
+   def_bool y if ARM64_4K_PAGES && ARM64_VA_BITS_39
+
 config CPU_BIG_ENDIAN
bool "Build big-endian kernel"
help
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index e94f945..f6e7480 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -41,11 +41,7 @@
  * The module space lives between the addresses given by TASK_SIZE
  * and PAGE_OFFSET - it must be within 128MB of the kernel text.
  */
-#ifdef CONFIG_ARM64_64K_PAGES
-#define VA_BITS(42)
-#else
-#define VA_BITS(39)
-#endif
+#define VA_BITS(CONFIG_ARM64_VA_BITS)
 #define PAGE_OFFSET(UL(0x) << (VA_BITS - 1))
 #define MODULES_END(PAGE_OFFSET)
 #define MODULES_VADDR  (MODULES_END - SZ_64M)
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 46bf666..268e53d 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -33,7 +33,7 @@
 
 #ifndef __ASSEMBLY__
 
-#ifdef CONFIG_ARM64_64K_PAGES
+#ifdef CONFIG_ARM64_2_LEVELS
 #include 
 #else
 #include 
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 9bea6e7..4829837 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,7 +26,7 @@
 
 #define check_pgt_cache()  do { } while (0)
 
-#ifndef CONFIG_ARM64_64K_PAGES
+#ifndef CONFIG_ARM64_2_LEVELS
 
 static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
 {
@@ -44,7 +44,7 @@ static inline void pud_populate(struct mm_struct *mm, pud_t 
*pud, pmd_t *pmd)
set_pud(pud, __pud(__pa(pmd) | PMD_TYPE_TABLE));
 }
 
-#endif /* CONFIG_ARM64_64K_PAGES */
+#endif /* CONFIG_ARM64_2_LEVELS */
 
 extern pgd_t *pgd_alloc(struct mm_struct *mm);
 extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h 
b/arch/arm64/include/asm/pgtable-hwdef.h
index 955e8c5..c7c603b 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -16,7 +16,7 @@
 #ifndef __ASM_PGTABLE_HWDEF_H
 #define __ASM_PGTABLE_HWDEF_H
 
-#ifdef CONFIG_ARM64_64K_PAGES
+#ifdef CONFIG_ARM64_2_LEVELS
 #include 
 #else
 #include 
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e4c60d6..4a350af 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -47,7 +47,7 @@ extern void __pmd_error(con

[PATCH v6 3/7] arm64: Add a description on 48-bit address space with 4KB pages

[Jungseok Lee]

This patch adds memory layout and translation lookup information
about 48-bit address space with 4K pages. The description is based
on 4 levels of translation tables.

Cc: Catalin Marinas 
Cc: Steve Capper 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
Acked-by: Kukjin Kim 
---
 Documentation/arm64/memory.txt |   59 ++--
 1 file changed, 51 insertions(+), 8 deletions(-)

diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index d50fa61..4c720d6 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -8,10 +8,11 @@ This document describes the virtual memory layout used by the 
AArch64
 Linux kernel. The architecture allows up to 4 levels of translation
 tables with a 4KB page size and up to 3 levels with a 64KB page size.
 
-AArch64 Linux uses 3 levels of translation tables with the 4KB page
-configuration, allowing 39-bit (512GB) virtual addresses for both user
-and kernel. With 64KB pages, only 2 levels of translation tables are
-used but the memory layout is the same.
+AArch64 Linux uses either 3 levels or 4 levels of translation tables with
+the 4KB page configuration, allowing 39-bit (512GB) or 48-bit (256TB)
+virtual addresses, respectively, for both user and kernel. With 64KB
+pages, only 2 levels of translation tables, allowing 42-bit (4TB)
+virtual address, are used but the memory layout is the same.
 
 User addresses have bits 63:39 set to 0 while the kernel addresses have
 the same bits set to 1. TTBRx selection is given by bit 63 of the
@@ -21,7 +22,7 @@ The swapper_pgd_dir address is written to TTBR1 and never 
written to
 TTBR0.
 
 
-AArch64 Linux memory layout with 4KB pages:
+AArch64 Linux memory layout with 4KB pages + 3 levels:
 
 Start  End SizeUse
 ---
@@ -48,7 +49,34 @@ ffbffc00 ffbf  64MB  
modules
 ffc0    256GB  kernel logical 
memory map
 
 
-AArch64 Linux memory layout with 64KB pages:
+AArch64 Linux memory layout with 4KB pages + 4 levels:
+
+Start  End SizeUse
+---
+    256TB  user
+
+   7bfe~124TB  vmalloc
+
+7bff   7bff  64KB  [guard page]
+
+7c00   7dff   2TB  vmemmap
+
+7e00   7bbf  ~2TB  [guard, future 
vmmemap]
+
+7a00   7aff  16MB  PCI I/O space
+
+7b00   7bbf  12MB  [guard]
+
+7bc0   7bdf   2MB  fixed mappings
+
+7be0   7bff   2MB  [guard]
+
+7c00   7fff  64MB  modules
+
+8000    128TB  kernel logical 
memory map
+
+
+AArch64 Linux memory layout with 64KB pages + 2 levels:
 
 Start  End SizeUse
 ---
@@ -75,7 +103,7 @@ fdfffc00 fdff  64MB  
modules
 fe00      2TB  kernel logical 
memory map
 
 
-Translation table lookup with 4KB pages:
+Translation table lookup with 4KB pages + 3 levels:
 
 +++++++++
 |6356|5548|4740|3932|3124|2316|15 8|7  0|
@@ -90,7 +118,22 @@ Translation table lookup with 4KB pages:
  +-> [63] TTBR0/1
 
 
-Translation table lookup with 64KB pages:
+Translation table lookup with 4KB pages + 4 levels:
+
++++++++++
+|6356|5548|4740|3932|3124|2316|15 8|7  0|
++++++++++
+ | | | | | |
+ | | | | | v
+ | | | | |   [11:0]  in-page offset
+ | | | | +-> [20:12] L3 index
+ | | | +---> [29:21] L2 index
+ | | +-> [38:30] L1 index
+ | +---> [47:39] L0 index
+ +-> [63] TTBR0/1
+
+
+Translation table lookup with 64KB pages + 2 levels:
 
 +++++++++
 |6356|55

[PATCH v6 7/7] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2

[Jungseok Lee]

This patch adds 4 levels of translation tables implementation for both
HYP and stage2.

Both symmetric and asymmetric configurations for page size and translation
levels are are validated on Fast Models:

 1) 4KB  + 3 levels guest on 4KB  + 4 levels host
 2) 4KB  + 4 levels guest on 4KB  + 4 levels host
 3) 64KB + 2 levels guest on 4KB  + 4 levels host
 4) 4KB  + 3 levels guest on 64KB + 2 levels host
 5) 4KB  + 4 levels guest on 64KB + 2 levels host
 6) 64KB + 2 levels guest on 64KB + 2 levels host

Cc: Marc Zyngier 
Cc: Christoffer Dall 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
Acked-by: Kukjin Kim 
---
 arch/arm/include/asm/kvm_mmu.h   |   10 +
 arch/arm/kvm/arm.c   |8 
 arch/arm/kvm/mmu.c   |   77 --
 arch/arm64/include/asm/kvm_arm.h |   12 ++
 arch/arm64/include/asm/kvm_mmu.h |   12 ++
 5 files changed, 108 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 5c7aa3c..36b9835 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -37,6 +37,11 @@
  */
 #define TRAMPOLINE_VA  UL(CONFIG_VECTORS_BASE)
 
+/*
+ * KVM_MMU_CACHE_MIN_PAGES is the number of stage2 page table translation 
levels.
+ */
+#define MMU_CACHE_MIN_PAGES2
+
 #ifndef __ASSEMBLY__
 
 #include 
@@ -94,6 +99,11 @@ static inline void kvm_clean_pgd(pgd_t *pgd)
clean_dcache_area(pgd, PTRS_PER_S2_PGD * sizeof(pgd_t));
 }
 
+static inline void kvm_clean_pmd(pmd_t *pmd)
+{
+   clean_dcache_area(pmd, PTRS_PER_PMD * sizeof(pmd_t));
+}
+
 static inline void kvm_clean_pmd_entry(pmd_t *pmd)
 {
clean_pmd_entry(pmd);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 9f19f2c..0785291 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -473,11 +473,19 @@ static int set_vttbr_baddr_mask(void)
 * 21 <= T0SZ <= 30 is valid under 3 level of translation tables
 * 30 <= T0SZ <= 39 is valid under 2 level of translation tables
 */
+#ifdef CONFIG_ARM64_3_LEVELS
if (t0sz <= 20) {
kvm_err("Cannot support %d-bit address space\n", 64 - t0sz);
return -EINVAL;
}
vttbr_x = 37 - t0sz;
+#else
+   if (t0sz <= 15) {
+   kvm_err("Cannot support %d-bit address space\n", 64 - t0sz);
+   return -EINVAL;
+   }
+   vttbr_x = 28 - t0sz;
+#endif
 #endif
vttbr_baddr_mask = (((1LLU << (48 - vttbr_x)) - 1) << (vttbr_x - 1));
 #endif
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 16f8049..6e2a0b0 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -390,13 +390,44 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned 
long start,
return 0;
 }
 
+static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
+  unsigned long end, unsigned long pfn,
+  pgprot_t prot)
+{
+   pud_t *pud;
+   pmd_t *pmd;
+   unsigned long addr, next;
+
+   addr = start;
+   do {
+   pud = pud_offset(pgd, addr);
+
+   if (pud_none_or_clear_bad(pud)) {
+   pmd = pmd_alloc_one(NULL, addr);
+   if (!pmd) {
+   kvm_err("Cannot allocate Hyp pmd\n");
+   return -ENOMEM;
+   }
+   pud_populate(NULL, pud, pmd);
+   get_page(virt_to_page(pud));
+   kvm_flush_dcache_to_poc(pud, sizeof(*pud));
+   }
+
+   next = pud_addr_end(addr, end);
+
+   create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
+   pfn += (next - addr) >> PAGE_SHIFT;
+   } while (addr = next, addr != end);
+
+   return 0;
+}
+
 static int __create_hyp_mappings(pgd_t *pgdp,
 unsigned long start, unsigned long end,
 unsigned long pfn, pgprot_t prot)
 {
pgd_t *pgd;
pud_t *pud;
-   pmd_t *pmd;
unsigned long addr, next;
int err = 0;
 
@@ -405,22 +436,21 @@ static int __create_hyp_mappings(pgd_t *pgdp,
end = PAGE_ALIGN(end);
do {
pgd = pgdp + pgd_index(addr);
-   pud = pud_offset(pgd, addr);
 
-   if (pud_none_or_clear_bad(pud)) {
-   pmd = pmd_alloc_one(NULL, addr);
-   if (!pmd) {
-   kvm_err("Cannot allocate Hyp pmd\n");
+   if (pgd_none(*pgd)) {
+   pud = pud_alloc_one(NULL, addr);
+   if (!pud) {
+   kvm_err("Cannot allocate Hyp pud\n");
err = -ENOMEM;
goto out;
}
-   pud_populate(NULL, pud, pmd);
-   get_p

[PATCH v6 5/7] arm64: mm: Implement 4 levels of translation tables

[Jungseok Lee]

This patch implements 4 levels of translation tables since 3 levels
of page tables with 4KB pages cannot support 40-bit physical address
space described in [1] due to the following issue.

It is a restriction that kernel logical memory map with 4KB + 3 levels
(0xffc0-0x) cannot cover RAM region from
544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
mapping for this region in map_mem function since __phys_to_virt for
this region reaches to address overflow.

If SoC design follows the document, [1], over 32GB RAM would be placed
from 544GB. Even 64GB system is supposed to use the region from 544GB
to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 levels
of page tables to avoid hacking __virt_to_phys and __phys_to_virt.

However, it is recommended 4 levels of page table should be only enabled
if memory map is too sparse or there is about 512GB RAM.

References
--
[1]: Principles of ARM Memory Maps, White Paper, Issue C

Cc: Catalin Marinas 
Cc: Steve Capper 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
Acked-by: Kukjin Kim 
Reviewed-by: Christoffer Dall 
Reviewed-by: Steve Capper 
---
 arch/arm64/Kconfig |8 +
 arch/arm64/include/asm/memblock.h  |6 
 arch/arm64/include/asm/page.h  |4 ++-
 arch/arm64/include/asm/pgalloc.h   |   20 
 arch/arm64/include/asm/pgtable-hwdef.h |6 ++--
 arch/arm64/include/asm/pgtable.h   |   45 ++
 arch/arm64/include/asm/tlb.h   |9 ++
 arch/arm64/kernel/head.S   |   54 +---
 arch/arm64/kernel/traps.c  |5 +++
 arch/arm64/mm/fault.c  |1 +
 arch/arm64/mm/mmu.c|   16 +++---
 11 files changed, 156 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9a28cbe..adbb8ea 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -182,12 +182,17 @@ config ARM64_VA_BITS_42
bool "42-bit"
depends on ARM64_64K_PAGES
 
+config ARM64_VA_BITS_48
+   bool "48-bit"
+   depends on ARM64_4K_PAGES
+
 endchoice
 
 config ARM64_VA_BITS
int
default 39 if ARM64_VA_BITS_39
default 42 if ARM64_VA_BITS_42
+   default 48 if ARM64_VA_BITS_48
 
 config ARM64_2_LEVELS
def_bool y if ARM64_64K_PAGES && ARM64_VA_BITS_42
@@ -195,6 +200,9 @@ config ARM64_2_LEVELS
 config ARM64_3_LEVELS
def_bool y if ARM64_4K_PAGES && ARM64_VA_BITS_39
 
+config ARM64_4_LEVELS
+   def_bool y if ARM64_4K_PAGES && ARM64_VA_BITS_48
+
 config CPU_BIG_ENDIAN
bool "Build big-endian kernel"
help
diff --git a/arch/arm64/include/asm/memblock.h 
b/arch/arm64/include/asm/memblock.h
index 6afeed2..e4ac8bf 100644
--- a/arch/arm64/include/asm/memblock.h
+++ b/arch/arm64/include/asm/memblock.h
@@ -16,6 +16,12 @@
 #ifndef __ASM_MEMBLOCK_H
 #define __ASM_MEMBLOCK_H
 
+#ifndef CONFIG_ARM64_4_LEVELS
+#define MEMBLOCK_INITIAL_LIMIT PGDIR_SIZE
+#else
+#define MEMBLOCK_INITIAL_LIMIT PUD_SIZE
+#endif
+
 extern void arm64_memblock_init(void);
 
 #endif
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 268e53d..83b5289 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -35,8 +35,10 @@
 
 #ifdef CONFIG_ARM64_2_LEVELS
 #include 
-#else
+#elif defined(CONFIG_ARM64_3_LEVELS)
 #include 
+#else
+#include 
 #endif
 
 extern void __cpu_clear_user_page(void *p, unsigned long user);
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 4829837..8d745fa 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,6 +26,26 @@
 
 #define check_pgt_cache()  do { } while (0)
 
+#ifdef CONFIG_ARM64_4_LEVELS
+
+static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
+{
+   return (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+static inline void pud_free(struct mm_struct *mm, pud_t *pud)
+{
+   BUG_ON((unsigned long)pud & (PAGE_SIZE-1));
+   free_page((unsigned long)pud);
+}
+
+static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
+{
+   set_pgd(pgd, __pgd(__pa(pud) | PUD_TYPE_TABLE));
+}
+
+#endif  /* CONFIG_ARM64_4_LEVELS */
+
 #ifndef CONFIG_ARM64_2_LEVELS
 
 static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h 
b/arch/arm64/include/asm/pgtable-hwdef.h
index c7c603b..fddcc3e 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -18,8 +18,10 @@
 
 #ifdef CONFIG_ARM64_2_LEVELS
 #include 
-#else
+#elif defined(CONFIG_ARM64_3_LEVELS)
 #include 
+#else
+#include 
 #endif
 
 /*
@@ -27,7 +29,7 @@
  *
  * Level 1 descriptor (PUD).
  */
-
+#define PUD_TYPE_TABLE (_AT(pudval_t, 3) << 0)
 #define PUD_TABLE_BIT  (_AT(pgdval_t, 1) << 

[PATCH v6 4/7] arm64: Add 4 levels of page tables definition with 4KB pages

[Jungseok Lee]

This patch adds hardware definition and types for 4 levels of
translation tables with 4KB pages.

Cc: Catalin Marinas 
Cc: Steve Capper 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
Acked-by: Kukjin Kim 
Reviewed-by: Christoffer Dall 
---
 arch/arm64/include/asm/pgtable-4level-hwdef.h |   50 +
 arch/arm64/include/asm/pgtable-4level-types.h |   71 +
 2 files changed, 121 insertions(+)
 create mode 100644 arch/arm64/include/asm/pgtable-4level-hwdef.h
 create mode 100644 arch/arm64/include/asm/pgtable-4level-types.h

diff --git a/arch/arm64/include/asm/pgtable-4level-hwdef.h 
b/arch/arm64/include/asm/pgtable-4level-hwdef.h
new file mode 100644
index 000..0ec84e2
--- /dev/null
+++ b/arch/arm64/include/asm/pgtable-4level-hwdef.h
@@ -0,0 +1,50 @@
+/*
+ * 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_PGTABLE_4LEVEL_HWDEF_H
+#define __ASM_PGTABLE_4LEVEL_HWDEF_H
+
+#define PTRS_PER_PTE   512
+#define PTRS_PER_PMD   512
+#define PTRS_PER_PUD   512
+#define PTRS_PER_PGD   512
+
+/*
+ * PGDIR_SHIFT determines the size a top-level page table entry can map.
+ */
+#define PGDIR_SHIFT39
+#define PGDIR_SIZE (_AC(1, UL) << PGDIR_SHIFT)
+#define PGDIR_MASK (~(PGDIR_SIZE-1))
+
+/*
+ * PUD_SHIFT determines the size the second level page table entry can map.
+ */
+#define PUD_SHIFT  30
+#define PUD_SIZE   (_AC(1, UL) << PUD_SHIFT)
+#define PUD_MASK   (~(PUD_SIZE-1))
+
+/*
+ * PMD_SHIFT determines the size the third level page table entry can map.
+ */
+#define PMD_SHIFT  21
+#define PMD_SIZE   (_AC(1, UL) << PMD_SHIFT)
+#define PMD_MASK   (~(PMD_SIZE-1))
+
+/*
+ * section address mask and size definitions.
+ */
+#define SECTION_SHIFT  21
+#define SECTION_SIZE   (_AC(1, UL) << SECTION_SHIFT)
+#define SECTION_MASK   (~(SECTION_SIZE-1))
+
+#endif
diff --git a/arch/arm64/include/asm/pgtable-4level-types.h 
b/arch/arm64/include/asm/pgtable-4level-types.h
new file mode 100644
index 000..7ad8dd2
--- /dev/null
+++ b/arch/arm64/include/asm/pgtable-4level-types.h
@@ -0,0 +1,71 @@
+/*
+ * 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_PGTABLE_4LEVEL_TYPES_H
+#define __ASM_PGTABLE_4LEVEL_TYPES_H
+
+#include 
+
+typedef u64 pteval_t;
+typedef u64 pmdval_t;
+typedef u64 pudval_t;
+typedef u64 pgdval_t;
+
+#undef STRICT_MM_TYPECHECKS
+
+#ifdef STRICT_MM_TYPECHECKS
+
+/*
+ * These are used to make use of C type-checking..
+ */
+typedef struct { pteval_t pte; } pte_t;
+typedef struct { pmdval_t pmd; } pmd_t;
+typedef struct { pudval_t pud; } pud_t;
+typedef struct { pgdval_t pgd; } pgd_t;
+typedef struct { pteval_t pgprot; } pgprot_t;
+
+#define pte_val(x) ((x).pte)
+#define pmd_val(x) ((x).pmd)
+#define pud_val(x) ((x).pud)
+#define pgd_val(x) ((x).pgd)
+#define pgprot_val(x)  ((x).pgprot)
+
+#define __pte(x)   ((pte_t) { (x) } )
+#define __pmd(x)   ((pmd_t) { (x) } )
+#define __pud(x)   ((pud_t) { (x) } )
+#define __pgd(x)   ((pgd_t) { (x) } )
+#define __pgprot(x)((pgprot_t) { (x) } )
+
+#else  /* !STRICT_MM_TYPECHECKS */
+
+typedef pteval_t pte_t;
+typedef pmdval_t pmd_t;
+typedef pudval_t pud_t;
+typedef pgdval_t pgd_t;
+typedef pteval_t pgprot_t;
+
+#define pte_val(x) (x)
+#define pmd_val(x) (x)
+#define pud_val(x) (x)
+#define pgd_val(x) (x)
+#define pgprot_val(x)  (x)
+
+#define __pte(x)   (x)
+#define __pmd(x)   (x)
+#define __pud(x)   (x)
+#define __pgd(x)   (x)
+#define __pgprot(x)(x)
+
+#endif /* STRICT_MM_TYPECHECKS */
+
+#endif /* __ASM_PGTABLE_4LEVEL_TYPES_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://

[PATCH v6 1/7] arm64: Use pr_* instead of printk

[Jungseok Lee]

This patch fixed the following checkpatch complaint as using pr_*
instead of printk.

WARNING: printk() should include KERN_ facility level

Cc: Catalin Marinas 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
Acked-by: Kukjin Kim 
---
 arch/arm64/kernel/traps.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index c43cfa9..506f781 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -156,7 +156,7 @@ static void dump_backtrace(struct pt_regs *regs, struct 
task_struct *tsk)
frame.pc = thread_saved_pc(tsk);
}
 
-   printk("Call trace:\n");
+   pr_emerg("Call trace:\n");
while (1) {
unsigned long where = frame.pc;
int ret;
@@ -331,17 +331,17 @@ asmlinkage void bad_mode(struct pt_regs *regs, int 
reason, unsigned int esr)
 
 void __pte_error(const char *file, int line, unsigned long val)
 {
-   printk("%s:%d: bad pte %016lx.\n", file, line, val);
+   pr_crit("%s:%d: bad pte %016lx.\n", file, line, val);
 }
 
 void __pmd_error(const char *file, int line, unsigned long val)
 {
-   printk("%s:%d: bad pmd %016lx.\n", file, line, val);
+   pr_crit("%s:%d: bad pmd %016lx.\n", file, line, val);
 }
 
 void __pgd_error(const char *file, int line, unsigned long val)
 {
-   printk("%s:%d: bad pgd %016lx.\n", file, line, val);
+   pr_crit("%s:%d: bad pgd %016lx.\n", file, line, val);
 }
 
 void __init trap_init(void)
-- 
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 v6 0/7] Support 4 levels of translation tables for ARM64

[Jungseok Lee]

Hi All,

This v6 patchset supports 4 levels of tranlsation tables for ARM64.

Firstly, the patchset introduces virtual address space size and
translation level options as taking account into the comment from
Catalin Marinas:
http://www.spinics.net/linux/lists/arm-kernel/msg319552.html

Then, it implements 4 levels of translation tables for native.

A dynamic VTTBR_X configuration is added before implementing 4 levels
for both HYP and stage2 sides.

All ARMv8 and ARMv7 related changes are validated with FastModels+kvmtool and
A15+QEMU, respectively.

Changes since v1:
- fixed unmatched data types as per Steve's comment
- removed unnecessary #ifdef in arch/arm64/mm/* as per Steve's comment
- revised create_pgd_entry to deal with PUD entry as per Steve's comment
- introduced a macro for initial memblock limit as per Steve's comment
- dropped "Fix line length exceeding 80 characters" patch as per Marc's comment
- removed unnecessary #ifdef in arch/arm/kvm/mmu.c as per Marc's comment
- added a macro for a number of objects of as per Marc's comment

Changes since v2:
- revised some macros in a generic way as per Marc's comment
- added a 2 level option for kvm mmu cache allocation as per Marc's comment

Changes since v3:
- added #ifdef to decide swapper and idmap size as per Steve's comment
- introduced Steve's create_pgd_entry

Changes since v4:
- hided translation level options from menuconfig as per Catalin's comment
- dropped some printk changes as per Mitchel's comment
- squashed VA_BITS related patches into a single patch

Changes since v5:
- added dynamic VTTBR_X configuration logic
- removed a redundant logic in stage2_set_pte as per Christoffer's comment
- added comments for create_pud_entry as per Christoffer and Steve's comment
- fixed typos in 4 level descriptions as per Christoffer's comment
- revised arm64 Kconfig help message as per Christoffer's comment
- rebased on top of for-next/core branch of arm64/linux.git

Jungseok Lee (7):
  arm64: Use pr_* instead of printk
  arm64: Introduce VA_BITS and translation level options
  arm64: Add a description on 48-bit address space with 4KB pages
  arm64: Add 4 levels of page tables definition with 4KB pages
  arm64: mm: Implement 4 levels of translation tables
  arm64: KVM: Set physical address size related factors in runtime
  arm64: KVM: Implement 4 levels of translation tables for HYP and
stage2

 Documentation/arm64/memory.txt|   59 +---
 arch/arm/include/asm/kvm_mmu.h|   10 +++
 arch/arm/kvm/arm.c|   90 -
 arch/arm/kvm/mmu.c|   77 ++---
 arch/arm64/Kconfig|   53 ++-
 arch/arm64/include/asm/kvm_arm.h  |   29 
 arch/arm64/include/asm/kvm_mmu.h  |   12 
 arch/arm64/include/asm/memblock.h |6 ++
 arch/arm64/include/asm/memory.h   |6 +-
 arch/arm64/include/asm/page.h |6 +-
 arch/arm64/include/asm/pgalloc.h  |   24 ++-
 arch/arm64/include/asm/pgtable-4level-hwdef.h |   50 ++
 arch/arm64/include/asm/pgtable-4level-types.h |   71 +++
 arch/arm64/include/asm/pgtable-hwdef.h|8 ++-
 arch/arm64/include/asm/pgtable.h  |   53 +--
 arch/arm64/include/asm/tlb.h  |   11 ++-
 arch/arm64/kernel/head.S  |   54 ---
 arch/arm64/kernel/traps.c |   13 ++--
 arch/arm64/kvm/hyp-init.S |   20 --
 arch/arm64/mm/fault.c |1 +
 arch/arm64/mm/mmu.c   |   16 +++--
 21 files changed, 592 insertions(+), 77 deletions(-)
 create mode 100644 arch/arm64/include/asm/pgtable-4level-hwdef.h
 create mode 100644 arch/arm64/include/asm/pgtable-4level-types.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

Re: [PATCH 0/8] i.MX6 PCIe binding change and MSI support

[Lucas Stach]

Hi Bjorn,

just a friendly reminder. It would be nice if you could pull those in.

Shawn already pulled the DT change and as it is a binding change this
means PCIe on i.MX6 is broken in -next, as long as the remaining patches
are missing.

Regards,
Lucas
 
Am Dienstag, den 29.04.2014, 14:31 +0200 schrieb Lucas Stach:
> Hi Bjorn,
> 
> Am Freitag, den 25.04.2014, 08:39 -0600 schrieb Bjorn Helgaas:
> [...]
> > >> >   PCI: designware: split Exynos and i.MX bindings
> > >> >   ARM: dts: imx6: update pcie to bring in line with new binding
> > >> >   PCI: imx6: use new clock names
> > >> >   PCI: imx6: drop old irq mapping
> > >> >   PCI: imx6: rip out optional (and unused) irqs
> > >> >   PCI: designware: make MSI isr shared irq aware
> > >> >   PCI: imx6: add support for MSI
> > >>
> > >> What's the status of all these?  I would normally apply patches 4-8 of 
> > >> this
> > >> series through my tree, given the appropriate acks, but I haven't seen
> > >> those yet.  And I'm not sure what dependencies there are between the
> > >> non-PCI patches and the PCI ones.
> > >>
> > > It's a complete binding change, so applying one part without the other
> > > is going to horribly break things.
> > >
> > > So I would at least want to see an ack for the binding change on the
> > > i.MX side from Shawn and Richard. This will need some follow on patches,
> > > as some boards adding PCIe using the old binding have cropped up in
> > > linux-next, but I can do the patches on short notice if everyone agrees
> > > to merge this patchset.
> > >
> > > The designware part is pretty simple and doesn't change anything for
> > > other users than i.MX. Though I would like to see an ack from Jingoo for
> > > those.
> > >
> > > I have some more stuff in the pipes regarding multiple MSI irqs, that
> > > depend on this series and also the Keystone people are waiting for this
> > > to be applied in order to consolidate the clock handling of the
> > > designware core driver, so it would be nice to get this moving again.
> > 
> > OK, just poke me again when you're ready for me to do something with these.
> > 
> 
> As both Richard and Jingoo gave their ack for the respective patches I
> think this is good to go in and I would expect all the PCI patches to go
> through your tree for 3.16.
> 
> Shawn, if you are not okay with this change, please speak up now.
> Otherwise please pick the dts change for 3.16. I'll go over linux-next
> and prepare the patches to fix up the boards there.
> 


-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
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

[no subject]

[Christian organization]

Good day,

We are Christian organization, we give loan to those who are in need,
please contact us at marieloanlend...@gmail.com



--
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

[RFC] ARM: EXYNOS: Add support for clock handling in power domain

[Arun Kumar K]

From: Prathyush K 

While powering on/off a local powerdomain in exynos5 chipsets, the input
clocks to each device gets modified. This behaviour is based on the
SYSCLK_SYS_PWR_REG registers.
E.g. SYSCLK_MFC_SYS_PWR_REG = 0x0, the parent of input clock to MFC
   (aclk333) gets modified to oscclk
= 0x1, no change in clocks.
The recommended value of SYSCLK_SYS_PWR_REG before power gating any
domain is 0x0. So we must also restore the clocks while powering on a
domain everytime.

This patch adds the framework for getting the required mux and parent clocks
through a power domain device node.
Just setting the parent while powering on is not enough since according
to the clock framework, the parent has never changed. So we set the
parent clock as oscclk before power gating and then set back the correct
parent clock after powering on a domain.

Signed-off-by: Prathyush K 
Signed-off-by: Andrew Bresticker 
Signed-off-by: Arun Kumar K 
---
This patch is posted for getting the opinion from all on what would
be the best possible solution to the issue at hand.
The issue is observed with multiple IPs like MFC, GSC, G2D, MSC etc.
where after a PD OFF-ON sequence, the parent clock gets reset to oscclk.
I would like to get the opinion from all on what would be the right
place to handle this. Either the clock re-parenting should be done
by all these individual IP drivers
OR
power-domain driver can handle this at a common place as is being done
in this patch.

One more possible change I can do is to make a exynos5250 compatible for
the power-domain driver and get the extra clocks only for exynos5 onwards.
But since there are no errors being reported even if these clocks are not
provided, these changes are fully backward compatible with exynos4 also.
---
 .../bindings/arm/exynos/power_domain.txt   |   18 +++
 arch/arm/mach-exynos/pm_domains.c  |   56 +++-
 2 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 5216b41..2e19a9f 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -9,6 +9,16 @@ Required Properties:
 - reg: physical base address of the controller and length of memory mapped
 region.
 
+Optional Properties:
+- clocks: List of clock handles. The parent clocks of the input clocks to the
+  devices in this power domain are set to oscclk before power gating and
+  restored back after powering on a domain. This is required for all domains
+  which are powered on and off and not required for unused domains.
+  The following clocks can be specified:
+  - oscclk: oscillator clock.
+  - clk(n): input clock to the devices in this power domain
+  - pclk(n): parent clock of input clock to the devices in this power domain
+
 Node of a device using power domains must have a samsung,power-domain property
 defined with a phandle to respective power domain.
 
@@ -19,6 +29,14 @@ Example:
reg = <0x10023C00 0x10>;
};
 
+   mfc_pd: power-domain@10044060 {
+   compatible = "samsung,exynos4210-pd";
+   reg = <0x10044060 0x20>;
+   clocks = <&clock CLK_FIN_PLL>, <&clock MOUT_SW_ACLK333>,
+   <&clock MOUT_USER_ACLK333>;
+   clock-names = "oscclk", "pclk0", "clk0";
+   };
+
 Example of the node using power domain:
 
node {
diff --git a/arch/arm/mach-exynos/pm_domains.c 
b/arch/arm/mach-exynos/pm_domains.c
index fe6570e..e5fe76d 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -24,6 +25,8 @@
 
 #include "regs-pmu.h"
 
+#define MAX_CLK_PER_DOMAIN 4
+
 /*
  * Exynos specific wrapper around the generic power domain
  */
@@ -32,6 +35,9 @@ struct exynos_pm_domain {
char const *name;
bool is_off;
struct generic_pm_domain pd;
+   struct clk *oscclk;
+   struct clk *clk[MAX_CLK_PER_DOMAIN];
+   struct clk *pclk[MAX_CLK_PER_DOMAIN];
 };
 
 static int exynos_pd_power(struct generic_pm_domain *domain, bool power_on)
@@ -44,6 +50,18 @@ static int exynos_pd_power(struct generic_pm_domain *domain, 
bool power_on)
pd = container_of(domain, struct exynos_pm_domain, pd);
base = pd->base;
 
+   /* Set oscclk before powering off a domain*/
+   if (!power_on) {
+   int i;
+   for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
+   if (!pd->clk[i])
+   break;
+   if (clk_set_parent(pd->clk[i], pd->oscclk))
+   pr_info("%s: error setting oscclk as parent to 
clock %d\n",
+   

Re: [RFC V2 0/3] drm/bridge: panel and chaining

[Andrzej Hajda]

On 05/09/2014 05:05 PM, Ajay kumar wrote:
> On Fri, May 9, 2014 at 7:29 PM, Rob Clark  wrote:
>> On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda  wrote:
>>> On 05/08/2014 08:24 PM, Rob Clark wrote:
 On Thu, May 8, 2014 at 2:41 AM, Andrzej Hajda  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 sta