Re: [PATCH] usb: dwc3: Keeping 'resource' related code together

[Vivek Gautam]

Hi,


On Wed, Jun 4, 2014 at 12:41 AM, Paul Zimmerman
 wrote:
>> From: linux-usb-ow...@vger.kernel.org 
>> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Vivek Gautam
>> Sent: Tuesday, June 03, 2014 3:40 AM
>>
>> Putting together the code related to getting the 'IORESOURCE_MEM'
>> and assigning the same to dwc->xhci_resources, for increasing
>> the readability.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>>
>> Based on 'next' branch of Felipe's usb tree.
>> Also cleanly applies to 'usb-next' branch of Greg's usb tree.
>>
>>  drivers/usb/dwc3/core.c |   38 +++---
>>  1 file changed, 19 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 3f59c12..4ca925d 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -656,6 +656,25 @@ static int dwc3_probe(struct platform_device *pdev)
>>   return -ENODEV;
>>   }
>>
>> + dwc->xhci_resources[0].start = res->start;
>> + dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
>> + DWC3_XHCI_REGS_END;
>> + dwc->xhci_resources[0].flags = res->flags;
>> + dwc->xhci_resources[0].name = res->name;
>> +
>> + res->start += DWC3_GLOBALS_REGS_START;
>> +
>> + /*
>> +  * Request memory region but exclude xHCI regs,
>> +  * since it will be requested by the xhci-plat driver.
>> +  */
>> + regs = devm_ioremap_resource(dev, res);
>> + if (IS_ERR(regs))
>> + return PTR_ERR(regs);
>> +
>> + dwc->regs   = regs;
>> + dwc->regs_size  = resource_size(res);
>> +
>>   if (node) {
>>   dwc->maximum_speed = of_usb_get_maximum_speed(node);
>
> I think this will break if the following dwc3_core_get_phy() call returns
> -EPROBE_DEFER. Since you have incremented res->start above, the next time
> this probe function is called, res->start will have the wrong value.
> Provided I'm reading the code correctly of course :)

True, my fault. This will surely throw an error in requesting memory
region the next time probe
is called.
Thanks for catching this.

>
> I think you could fix that by decrementing res->start back to its
> original value just after the call to resource_size() above.

Sure will put
res->start -= DWC3_GLOBALS_REGS_START;
right after the call to resource_size() call.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] s5p-mfc: Adding MFC v7 and v8 firmwares

[Arun Kumar K]

Hi Ben,

On Wed, Jun 4, 2014 at 4:56 AM, Ben Hutchings  wrote:
> On Tue, 2014-06-03 at 20:34 +0100, Ben Hutchings wrote:
>> On Wed, 2014-05-21 at 18:11 +0530, Arun Kumar K wrote:
>> > Adding the following firmware files for MFC
>> > s5p-mfc-v7.fw: Used in exynos 5420
>> > s5p-mfc-v8.fw: Used in exynos 5800
>> >
>> > Signed-off-by: Arun Kumar K 
>> > ---
>> > Changes from v1
>> > - None
>> > ---
>> >  WHENCE|2 ++
>> >  s5p-mfc/s5p-mfc-v7.fw |  Bin 0 -> 382724 bytes
>> >  s5p-mfc/s5p-mfc-v8.fw |  Bin 0 -> 360576 bytes
>> >  3 files changed, 2 insertions(+)
>> >  create mode 100644 s5p-mfc/s5p-mfc-v7.fw
>> >  create mode 100644 s5p-mfc/s5p-mfc-v8.fw
>> [...]
>>
>> Applied, thanks.
>
> Just noticed a problem with all the s5p-mfc firmware: you are putting it
> in the s5p-mfc subdirectory, so distribution packages will install them
> in /lib/firmware/s5p-mfc.  However, unless I'm mistaken your driver
> requests it with a bare filename (e.g. "s5p-mfc-v7.fw") so it won't be
> found.
>

Yes this issue is there.
Kamil, are you ok with changing the fw load path to s5p-mfc/s5p-mfc*.fw
in the driver?

Regards
Arun

> Ben.
>
> --
> Ben Hutchings
> Experience is what causes a person to make new mistakes instead of old ones.
--
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: mct: Don't reset the counter during boot and resume

[Kukjin Kim]

Doug Anderson wrote:
> 
> Chirantan,
> 
> On Tue, Jun 3, 2014 at 11:48 AM, Chirantan Ekbote
>  wrote:
> > Unfortunately on some exynos systems, resetting the mct counter also
> > resets the architected timer counter.  This can cause problems if the
> > architected timer driver has already been initialized because the kernel
> > will think that the counter has wrapped around, causing a big jump in
> > printk timestamps and delaying any scheduled clock events until the
> > counter reaches the value it had before it was reset.
> >
> > The kernel code makes no assumptions about the initial value of the mct
> > counter so there is no reason from a software perspective to clear the
> > counter before starting it.  This also fixes the problems described in
> > the previous paragraph.
> >
> > Cc: Olof Johansson 
> > Cc: Doug Anderson 
> > Cc: Kukjin Kim 
> > Cc: Tomasz Figa 
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-soc@vger.kernel.org
> > Signed-off-by: Chirantan Ekbote 
> > ---
> >  drivers/clocksource/exynos_mct.c | 9 +++--
> >  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> I can confirm that this fixes problems I described in
> .  Now
> when I boot there's no mysterious delay and there's no big jump in
> time.
> 
> I'd love to see this in 3.16 so we can get rid of this annoying delay.
> 
> Reviewed-by: Doug Anderson 
> Tested-by: Doug Anderson 

OK, I will queue this patch into fixes for 3.16.

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: exynos5: Remove multi core timer

[Kukjin Kim]

Chirantan Ekbote wrote:
> 
> Hi Kukjin,
> 
Hi,

> On Wed, May 21, 2014 at 5:47 AM, Kukjin Kim  wrote:
> > Yeah, actually we don't need to reset the count value after suspend/resume.
> > So, how about following? I think, it should be fine to you.
> >
> > diff --git a/drivers/clocksource/exynos_mct.c 
> > b/drivers/clocksource/exynos_mct.c
> > index 8d64200..d24db6f 100644
> > --- a/drivers/clocksource/exynos_mct.c
> > +++ b/drivers/clocksource/exynos_mct.c
> > @@ -157,12 +157,15 @@ static void exynos4_mct_frc_start(u32 hi, u32 lo)
> >  {
> > u32 reg;
> >
> > -   exynos4_mct_write(lo, EXYNOS4_MCT_G_CNT_L);
> > -   exynos4_mct_write(hi, EXYNOS4_MCT_G_CNT_U);
> > -
> > reg = __raw_readl(reg_base + EXYNOS4_MCT_G_TCON);
> > -   reg |= MCT_G_TCON_START;
> > -   exynos4_mct_write(reg, EXYNOS4_MCT_G_TCON);
> > +
> > +   if (!(reg & MCT_G_TCON_START)) {
> > +   exynos4_mct_write(lo, EXYNOS4_MCT_G_CNT_L);
> > +   exynos4_mct_write(hi, EXYNOS4_MCT_G_CNT_U);
> > +
> > +   reg |= MCT_G_TCON_START;
> > +   exynos4_mct_write(reg, EXYNOS4_MCT_G_TCON);
> > +   }
> >  }
> >
> >
> 
> As Doug mentioned, this seems more complicated than necessary since
> the kernel doesn't care about the initial value of the mct counter at
> all.  Is there some reason from a hardware standpoint that the counter
> needs to be cleared?  If not, I would rather just delete the two
> offending lines.  I am sending a patch that does this instead.
> 
So decision point is that the initialization of MCT counter is required or not
when kernel begins. Yes it doesn't matter, basically MCT start has no problem
with any initial value and additionally its hardware reset value is 0x0.

OK, your suggestion is fair enough.

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: mct: Don't reset the counter during boot and resume

[Doug Anderson]

Chirantan,

On Tue, Jun 3, 2014 at 11:48 AM, Chirantan Ekbote
 wrote:
> Unfortunately on some exynos systems, resetting the mct counter also
> resets the architected timer counter.  This can cause problems if the
> architected timer driver has already been initialized because the kernel
> will think that the counter has wrapped around, causing a big jump in
> printk timestamps and delaying any scheduled clock events until the
> counter reaches the value it had before it was reset.
>
> The kernel code makes no assumptions about the initial value of the mct
> counter so there is no reason from a software perspective to clear the
> counter before starting it.  This also fixes the problems described in
> the previous paragraph.
>
> Cc: Olof Johansson 
> Cc: Doug Anderson 
> Cc: Kukjin Kim 
> Cc: Tomasz Figa 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Chirantan Ekbote 
> ---
>  drivers/clocksource/exynos_mct.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)

I can confirm that this fixes problems I described in
.  Now
when I boot there's no mysterious delay and there's no big jump in
time.

I'd love to see this in 3.16 so we can get rid of this annoying delay.

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

Re: [PATCH v2 2/2] s5p-mfc: Adding MFC v7 and v8 firmwares

[Ben Hutchings]

On Tue, 2014-06-03 at 20:34 +0100, Ben Hutchings wrote:
> On Wed, 2014-05-21 at 18:11 +0530, Arun Kumar K wrote:
> > Adding the following firmware files for MFC
> > s5p-mfc-v7.fw: Used in exynos 5420
> > s5p-mfc-v8.fw: Used in exynos 5800
> > 
> > Signed-off-by: Arun Kumar K 
> > ---
> > Changes from v1
> > - None
> > ---
> >  WHENCE|2 ++
> >  s5p-mfc/s5p-mfc-v7.fw |  Bin 0 -> 382724 bytes
> >  s5p-mfc/s5p-mfc-v8.fw |  Bin 0 -> 360576 bytes
> >  3 files changed, 2 insertions(+)
> >  create mode 100644 s5p-mfc/s5p-mfc-v7.fw
> >  create mode 100644 s5p-mfc/s5p-mfc-v8.fw
> [...]
> 
> Applied, thanks.

Just noticed a problem with all the s5p-mfc firmware: you are putting it
in the s5p-mfc subdirectory, so distribution packages will install them
in /lib/firmware/s5p-mfc.  However, unless I'm mistaken your driver
requests it with a bare filename (e.g. "s5p-mfc-v7.fw") so it won't be
found.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 2/2] s5p-mfc: Adding MFC v7 and v8 firmwares

[Ben Hutchings]

On Wed, 2014-05-21 at 18:11 +0530, Arun Kumar K wrote:
> Adding the following firmware files for MFC
> s5p-mfc-v7.fw: Used in exynos 5420
> s5p-mfc-v8.fw: Used in exynos 5800
> 
> Signed-off-by: Arun Kumar K 
> ---
> Changes from v1
> - None
> ---
>  WHENCE|2 ++
>  s5p-mfc/s5p-mfc-v7.fw |  Bin 0 -> 382724 bytes
>  s5p-mfc/s5p-mfc-v8.fw |  Bin 0 -> 360576 bytes
>  3 files changed, 2 insertions(+)
>  create mode 100644 s5p-mfc/s5p-mfc-v7.fw
>  create mode 100644 s5p-mfc/s5p-mfc-v8.fw
[...]

Applied, thanks.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 1/2] s5p-mfc: Add s5p-mfc-v6-v2 firmware

[Ben Hutchings]

On Wed, 2014-05-21 at 18:11 +0530, Arun Kumar K wrote:
> This is the newer version of mfc-v6 firmware which can
> be used in exynos5250 based boards. This has many bug fixes
> and enhancements. To maintain backward compatibility, the older
> firmware file is still retained and the new file is added with
> the name s5p-mfc-v6-v2.fw. This new firmware handling is supported
> with the below patches in s5p-mfc driver:
> s5p-mfc: Support multiple firmware sub-versions
> s5p-mfc: Add init buffer cmd to MFCV6
> 
> Signed-off-by: Arun Kumar K 
> ---
> Changes from v1
> - Made into a new file instead of upgrading old v6 firmware
> ---
>  WHENCE   |7 ---
>  s5p-mfc/s5p-mfc-v6-v2.fw |  Bin 0 -> 343756 bytes
>  2 files changed, 4 insertions(+), 3 deletions(-)
>  create mode 100644 s5p-mfc/s5p-mfc-v6-v2.fw
[...]

Applied, thanks.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.


signature.asc
Description: This is a digitally signed message part

RE: [PATCH] usb: dwc3: Keeping 'resource' related code together

[Paul Zimmerman]

> From: linux-usb-ow...@vger.kernel.org 
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Vivek Gautam
> Sent: Tuesday, June 03, 2014 3:40 AM
> 
> Putting together the code related to getting the 'IORESOURCE_MEM'
> and assigning the same to dwc->xhci_resources, for increasing
> the readability.
> 
> Signed-off-by: Vivek Gautam 
> ---
> 
> Based on 'next' branch of Felipe's usb tree.
> Also cleanly applies to 'usb-next' branch of Greg's usb tree.
> 
>  drivers/usb/dwc3/core.c |   38 +++---
>  1 file changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 3f59c12..4ca925d 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -656,6 +656,25 @@ static int dwc3_probe(struct platform_device *pdev)
>   return -ENODEV;
>   }
> 
> + dwc->xhci_resources[0].start = res->start;
> + dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
> + DWC3_XHCI_REGS_END;
> + dwc->xhci_resources[0].flags = res->flags;
> + dwc->xhci_resources[0].name = res->name;
> +
> + res->start += DWC3_GLOBALS_REGS_START;
> +
> + /*
> +  * Request memory region but exclude xHCI regs,
> +  * since it will be requested by the xhci-plat driver.
> +  */
> + regs = devm_ioremap_resource(dev, res);
> + if (IS_ERR(regs))
> + return PTR_ERR(regs);
> +
> + dwc->regs   = regs;
> + dwc->regs_size  = resource_size(res);
> +
>   if (node) {
>   dwc->maximum_speed = of_usb_get_maximum_speed(node);

I think this will break if the following dwc3_core_get_phy() call returns
-EPROBE_DEFER. Since you have incremented res->start above, the next time
this probe function is called, res->start will have the wrong value.
Provided I'm reading the code correctly of course :)

I think you could fix that by decrementing res->start back to its
original value just after the call to resource_size() above.

-- 
Paul

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

[PATCH] arm: mct: Don't reset the counter during boot and resume

[Chirantan Ekbote]

Unfortunately on some exynos systems, resetting the mct counter also
resets the architected timer counter.  This can cause problems if the
architected timer driver has already been initialized because the kernel
will think that the counter has wrapped around, causing a big jump in
printk timestamps and delaying any scheduled clock events until the
counter reaches the value it had before it was reset.

The kernel code makes no assumptions about the initial value of the mct
counter so there is no reason from a software perspective to clear the
counter before starting it.  This also fixes the problems described in
the previous paragraph.

Cc: Olof Johansson 
Cc: Doug Anderson 
Cc: Kukjin Kim 
Cc: Tomasz Figa 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Chirantan Ekbote 
---
 drivers/clocksource/exynos_mct.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index acf5a32..9b4a0ae 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -152,13 +152,10 @@ static void exynos4_mct_write(unsigned int value, 
unsigned long offset)
 }
 
 /* Clocksource handling */
-static void exynos4_mct_frc_start(u32 hi, u32 lo)
+static void exynos4_mct_frc_start(void)
 {
u32 reg;
 
-   exynos4_mct_write(lo, EXYNOS4_MCT_G_CNT_L);
-   exynos4_mct_write(hi, EXYNOS4_MCT_G_CNT_U);
-
reg = __raw_readl(reg_base + EXYNOS4_MCT_G_TCON);
reg |= MCT_G_TCON_START;
exynos4_mct_write(reg, EXYNOS4_MCT_G_TCON);
@@ -180,7 +177,7 @@ static cycle_t exynos4_frc_read(struct clocksource *cs)
 
 static void exynos4_frc_resume(struct clocksource *cs)
 {
-   exynos4_mct_frc_start(0, 0);
+   exynos4_mct_frc_start();
 }
 
 struct clocksource mct_frc = {
@@ -194,7 +191,7 @@ struct clocksource mct_frc = {
 
 static void __init exynos4_clocksource_init(void)
 {
-   exynos4_mct_frc_start(0, 0);
+   exynos4_mct_frc_start();
 
if (clocksource_register_hz(&mct_frc, clk_rate))
panic("%s: can't register clocksource\n", mct_frc.name);
-- 
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] arm: dts: exynos5: Remove multi core timer

[Chirantan Ekbote]

Hi Kukjin,

On Wed, May 21, 2014 at 5:47 AM, Kukjin Kim  wrote:
> Yeah, actually we don't need to reset the count value after suspend/resume.
> So, how about following? I think, it should be fine to you.
>
> diff --git a/drivers/clocksource/exynos_mct.c 
> b/drivers/clocksource/exynos_mct.c
> index 8d64200..d24db6f 100644
> --- a/drivers/clocksource/exynos_mct.c
> +++ b/drivers/clocksource/exynos_mct.c
> @@ -157,12 +157,15 @@ static void exynos4_mct_frc_start(u32 hi, u32 lo)
>  {
> u32 reg;
>
> -   exynos4_mct_write(lo, EXYNOS4_MCT_G_CNT_L);
> -   exynos4_mct_write(hi, EXYNOS4_MCT_G_CNT_U);
> -
> reg = __raw_readl(reg_base + EXYNOS4_MCT_G_TCON);
> -   reg |= MCT_G_TCON_START;
> -   exynos4_mct_write(reg, EXYNOS4_MCT_G_TCON);
> +
> +   if (!(reg & MCT_G_TCON_START)) {
> +   exynos4_mct_write(lo, EXYNOS4_MCT_G_CNT_L);
> +   exynos4_mct_write(hi, EXYNOS4_MCT_G_CNT_U);
> +
> +   reg |= MCT_G_TCON_START;
> +   exynos4_mct_write(reg, EXYNOS4_MCT_G_TCON);
> +   }
>  }
>
>

As Doug mentioned, this seems more complicated than necessary since
the kernel doesn't care about the initial value of the mct counter at
all.  Is there some reason from a hardware standpoint that the counter
needs to be cleared?  If not, I would rather just delete the two
offending lines.  I am sending a patch that does this instead.

Cheers,
Chirantan
--
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

[Bjorn Helgaas]

On Tue, Jun 3, 2014 at 7:22 AM, Lucas Stach  wrote:
> Hello Bjorn,
>
> Am Freitag, den 30.05.2014, 11:30 -0600 schrieb Bjorn Helgaas:
>> On Mon, May 12, 2014 at 10:59:43AM +0200, Lucas Stach wrote:
>> > 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.
>>
>> I applied these to pci/host-imx6 for v3.16.
>>
>> Sorry I didn't do this sooner; I get a lot of email and it's easy to
>> overlook things.  I mostly work from patchwork
>> (http://patchwork.ozlabs.org/project/linux-pci/list/?order=date), and I had
>> dropped this series from there because there was enough discussion that I
>> expected a re-post, so it wasn't on my radar screen anymore.
>>
>> Bjorn
>>
>> > 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
>
> It seems you missed this one patch. This isn't too urgent, as it is just
> the doc update, but it should still go into 3.16 along with the other
> changes. I would have expected that is ok for this to go through your
> tree.

Oops, sorry.  I had mentioned patches 4-8 earlier in the conversation,
so that's what I merged.

I added patch 2 to pci/host-imx6, and I'll ask Linus to pull it later
along with some other things I forgot.  Thanks for the reminder!

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

Re: [PATCHv3 3/4] mmc: dw_mmc: remove the "supports-highspeed" property.

[Mark Rutland]

On Fri, May 30, 2014 at 09:01:16AM +0100, Ulf Hansson wrote:
> On 28 May 2014 07:35, Jaehoon Chung  wrote:
> > Removed the parser for "supports-highspeed".
> > It can be parsed with "cap-mmc-highsped" or "cap-sd-highspeed" at
> > mmc_of_parse().
> >
> > Signed-off-by: Jaehoon Chung 
> > ---
> >  drivers/mmc/host/dw_mmc.c |3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> > index 3285bdd..34b5210 100644
> > --- a/drivers/mmc/host/dw_mmc.c
> > +++ b/drivers/mmc/host/dw_mmc.c
> > @@ -2281,9 +2281,6 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
> > dw_mci *host)
> > return ERR_PTR(ret);
> > }
> >
> > -   if (of_find_property(np, "supports-highspeed", NULL))
> > -   pdata->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
> > -
> 
> According to DT guys, normally we shouldn't remove DT bindings. Thus,
> you need to keep this, unless you can get some of the DT guys to ack
> it.

In general, yes. Unless there's a compelling reason to drop a binding,
and all users are happy with it being dropped, then there's not much
point in removing it. It's usually not possible to get agreement because
it's usually nto possible to know the full set of users, so in general
we can't drop or change stuff.

> Though, you still want to move the DTs to use common mmc bindings. And
> you could mark the documentation of the above binding as deprecated.

Deprecated bindings can be supported even if discouraged. As far as I
can see, keeping the existing binding along side the new one looks
relatively simple in this case.

Thanks,
Mark.
--
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]

Hello Bjorn,

Am Freitag, den 30.05.2014, 11:30 -0600 schrieb Bjorn Helgaas:
> On Mon, May 12, 2014 at 10:59:43AM +0200, Lucas Stach wrote:
> > 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.
> 
> I applied these to pci/host-imx6 for v3.16.
> 
> Sorry I didn't do this sooner; I get a lot of email and it's easy to
> overlook things.  I mostly work from patchwork
> (http://patchwork.ozlabs.org/project/linux-pci/list/?order=date), and I had
> dropped this series from there because there was enough discussion that I
> expected a re-post, so it wasn't on my radar screen anymore.
> 
> Bjorn
> 
> > 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

It seems you missed this one patch. This isn't too urgent, as it is just
the doc update, but it should still go into 3.16 along with the other
changes. I would have expected that is ok for this to go through your
tree.

Regards,
Lucas
-- 
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

Re: [RFC V3 2/3] drm/bridge: add a dummy panel driver to support lvds bridges

[Andrzej Hajda]

On 06/03/2014 11:58 AM, Ajay kumar wrote:
> On Tue, May 20, 2014 at 1:40 AM, Thierry Reding
>  wrote:
>> On Tue, May 20, 2014 at 12:37:38AM +0530, Ajay kumar wrote:
>>> On 5/19/14, Thierry Reding  wrote:
 On Sun, May 18, 2014 at 01:50:36PM +0530, Ajay kumar wrote:
> On Sun, May 18, 2014 at 2:44 AM, Thierry Reding
>  wrote:
>> On Thu, May 15, 2014 at 05:10:16PM +0530, Ajay kumar wrote:
>>> On Thu, May 15, 2014 at 1:43 PM, Thierry Reding
>>>  wrote:
>> [...]
 I still don't see how controlling the enable GPIO from the panel will
 be
 in any way better, or different for that matter, from simply
 enabling
 the backlight and let the backlight driver handle the enable GPIO.
 Have
 you tried to do that and found that it doesn't work?
>>> It works, but it gives me glitch when I try to configure video.
>>> This is because backlight_on(pwm-backlight) happens much before
>>> I configure video(inside drm), and while configuring video there would
>>> be a glitch,
>>> and that glitch would be visible to the user since backlight is already
>>> enabled.
>> Okay, so this means that your backlight is turned on too early. Instead
>> of working around that problem by moving control of the backlight
>> enable
>> GPIO from the backlight driver into the panel driver, the correct way
>> to
>> fix it is to make sure the backlight stays off until video is ready.
> Ok. Please suggest an idea how to do the same!
 I did post a patch[0] a long time ago that added a way to fix this for
 pwm-backlight at least.
>>> I have tried this. We have to wait till the userspace to switch the
>>> backlight on again :(
>> Erm... why?
> Because, backlight remains in powerdown state till the userspace startup 
> scripts
> turn it back on!
>
> I have already suggested a simple idea which conforms to a valid spec.
> Just because enable_gpio is already a part of pwm_bl.c, I somewhat feel
> like we are forcing people to handle enable_gpio inside pwm_bl.c.
 And that's a good thing. That's what people will expect. Backlights are
 exposed via sysfs, which is currently also the only way to control the
 backlight from userspace. If the driver for that doesn't have everything
 required to control the backlight how can userspace control it?
>>> This is a valid point, only at the hardware level.
>>> But if you consider a user experience perspective,
>>> user still will not be able to see the backlight even
>>> though enable_gpio is controlled elsewhere, since
>>> pwm is disabled anyhow.
>> But that's precisely my point. If the enable_gpio is controlled
>> elsewhere there will be no way for the userspace interface to enable the
>> backlight.
> Hmm, this is a valid point. Still, see my explanation below.[1]
>
>>> Now lets talk about backlight_on case. Even though user tries to turn
>>> on the backlight, and the driver turns on backlight supply, pwm and
>>> enable_gpio, the driver cannot always guarantee him that backlight is
>>> "really on" since it also depends on panel power.
>> No. If the backlight is properly hooked up to all resources, then
>> turning it on will *really turn it on*.
> [1] : This is what I am trying to elaborate.
> Backlight really does depend on panel power also, and
> you cannot tie LCD resources to backlight driver.
> Now, consider that panel/LCD is off and user wishes to control backlight,
> it will have no effect.
> So, ideally backlight drivers are not "completely independent" in generating
> backlight in most of the cases.
> LCD driver and backlight driver should both co ordinate at user/kernel level
> to make things work properly.
>
> Lets consider this also as a similar case - "backlight enable being handled in
> panel driver."
> Here also, things will work if LCD and backlight drivers work in tandem,
> at user space.
>
> Note that, pwm_bl can still work properly without enabling the backlight
> GPIO.
> And, I did point out to a valid datasheet from AUO, which clearly
> indicates why
> backlight enable GPIO should be a part of panel driver and not pwm_bl
> driver.
 Just because some spec mentions the backlight enable pin in some panel
 power up sequence diagram that doesn't mean we have to implement it as
 part of the panel driver.
>>> That is not "some spec". I believe all the AUO panels share the same
>>> sequence!
>> Just because some specs mention the backlight enable pin in some panel
>> power up sequence diagram that doesn't mean we have to implement it as
>> part of the panel driver.
>> Thierry

My two cents. I have took some random panel specs with separate backlight:
- LD070WX3 - implemented in Linux as simple panel [1],
- LP129QE1 - again implemented as simple panel [2].
Both panels requires that backlight should be turned on after 200ms of
valid video data and
turned off 200ms before end of video data.

[1]: http://www.di

Re: [PATCH 1/1] i2c: s3c2410: Remove class based instantiation

[Tomasz Figa]

On 03.06.2014 14:17, Wolfram Sang wrote:
> 
>> Couldn't it be made configurable with a Kconfig entry? E.g. "Enable
>> deprecated class-based instantiation" under Drivers / I2C? Turning it
>> off could make the code ignore the class field completely.
> 
> Technically, yes. But we could also wait another cycle and just be done
> with it :)
> 

OK, if it's just one cycle, then it wouldn't make sense indeed. Thanks
for clarification.

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 1/1] i2c: s3c2410: Remove class based instantiation

[Wolfram Sang]

> Couldn't it be made configurable with a Kconfig entry? E.g. "Enable
> deprecated class-based instantiation" under Drivers / I2C? Turning it
> off could make the code ignore the class field completely.

Technically, yes. But we could also wait another cycle and just be done
with it :)



signature.asc
Description: Digital signature

Re: [PATCH 1/1] i2c: s3c2410: Remove class based instantiation

[Tomasz Figa]

Hi Wolfram, Sachin,

On 03.06.2014 13:21, Sachin Kamat wrote:
> Hi Wolfram,
> 
> On Tue, Jun 3, 2014 at 3:35 PM, Wolfram Sang  wrote:
>> On Tue, Jun 03, 2014 at 02:30:22PM +0530, Sachin Kamat wrote:
>>> With multiplatform support enabled for Exynos, class based
>>> instantiation causes a boot time delay due to I2C_CLASS_HWMON
>>> triggered probe. Since class based instantiation has been
>>> deprecated since some time now, remove it for Samsung I2C driver.
>>>
>>> Signed-off-by: Sachin Kamat 
>>> Cc: Olof Johansson 
>>
>> In my book, not long enough. I suggest I will take care of the removal.
>> I'll do it for all class deprecating drivers.

Couldn't it be made configurable with a Kconfig entry? E.g. "Enable
deprecated class-based instantiation" under Drivers / I2C? Turning it
off could make the code ignore the class field completely.

This way people that don't want it could just disable it and others
could also test whether disabling it affects them in any way.

> 
> The reason for the removal is the boot delay it is causing on Exynos 5250
> based boards by throwing the following errors continuously.
> 
> [   55.005300] s3c-i2c 12ce.i2c: cannot get bus (error -110)
> [   59.005300] s3c-i2c 12ce.i2c: cannot get bus (error -110)
> [   63.005300] s3c-i2c 12ce.i2c: cannot get bus (error -110)

Are you sure this is directly related to class-based instantiation? This
looks like the bus being driven low by some external component or
incorrectly configured pins. What is this bus used for on affected board?

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 1/1] i2c: s3c2410: Remove class based instantiation

[Wolfram Sang]

> The reason for the removal is the boot delay it is causing on Exynos 5250
> based boards by throwing the following errors continuously.
> 
> [   55.005300] s3c-i2c 12ce.i2c: cannot get bus (error -110)
> [   59.005300] s3c-i2c 12ce.i2c: cannot get bus (error -110)
> [   63.005300] s3c-i2c 12ce.i2c: cannot get bus (error -110)

I know. That's why I implemented the deprecated class. Still, users may
need more time to switch over. Keep it an out-of-tree patch until then.



signature.asc
Description: Digital signature

Re: [PATCH] serial: samsung: fix typo in debug code

[Sachin Kamat]

Hi Arnd,

On Tue, Jun 3, 2014 at 3:23 PM, Arnd Bergmann  wrote:
> commit e4ac92df2791 ("serial: samsung: Neaten dbg uses") introduced
> a regression in the conversion from vsprintf to vsnprintf.
>
> This fixes the build error by passing the correct variable name.

I submitted a similar patch sometime back.
http://www.spinics.net/lists/linux-serial/msg12843.html

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

Re: [PATCH 1/1] i2c: s3c2410: Remove class based instantiation

[Sachin Kamat]

Hi Wolfram,

On Tue, Jun 3, 2014 at 3:35 PM, Wolfram Sang  wrote:
> On Tue, Jun 03, 2014 at 02:30:22PM +0530, Sachin Kamat wrote:
>> With multiplatform support enabled for Exynos, class based
>> instantiation causes a boot time delay due to I2C_CLASS_HWMON
>> triggered probe. Since class based instantiation has been
>> deprecated since some time now, remove it for Samsung I2C driver.
>>
>> Signed-off-by: Sachin Kamat 
>> Cc: Olof Johansson 
>
> In my book, not long enough. I suggest I will take care of the removal.
> I'll do it for all class deprecating drivers.

The reason for the removal is the boot delay it is causing on Exynos 5250
based boards by throwing the following errors continuously.

[   55.005300] s3c-i2c 12ce.i2c: cannot get bus (error -110)
[   59.005300] s3c-i2c 12ce.i2c: cannot get bus (error -110)
[   63.005300] s3c-i2c 12ce.i2c: cannot get bus (error -110)

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

[PATCH] usb: dwc3: Keeping 'resource' related code together

[Vivek Gautam]

Putting together the code related to getting the 'IORESOURCE_MEM'
and assigning the same to dwc->xhci_resources, for increasing
the readability.

Signed-off-by: Vivek Gautam 
---

Based on 'next' branch of Felipe's usb tree.
Also cleanly applies to 'usb-next' branch of Greg's usb tree.

 drivers/usb/dwc3/core.c |   38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 3f59c12..4ca925d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -656,6 +656,25 @@ static int dwc3_probe(struct platform_device *pdev)
return -ENODEV;
}
 
+   dwc->xhci_resources[0].start = res->start;
+   dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
+   DWC3_XHCI_REGS_END;
+   dwc->xhci_resources[0].flags = res->flags;
+   dwc->xhci_resources[0].name = res->name;
+
+   res->start += DWC3_GLOBALS_REGS_START;
+
+   /*
+* Request memory region but exclude xHCI regs,
+* since it will be requested by the xhci-plat driver.
+*/
+   regs = devm_ioremap_resource(dev, res);
+   if (IS_ERR(regs))
+   return PTR_ERR(regs);
+
+   dwc->regs   = regs;
+   dwc->regs_size  = resource_size(res);
+
if (node) {
dwc->maximum_speed = of_usb_get_maximum_speed(node);
 
@@ -676,28 +695,9 @@ static int dwc3_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   dwc->xhci_resources[0].start = res->start;
-   dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
-   DWC3_XHCI_REGS_END;
-   dwc->xhci_resources[0].flags = res->flags;
-   dwc->xhci_resources[0].name = res->name;
-
-   res->start += DWC3_GLOBALS_REGS_START;
-
-   /*
-* Request memory region but exclude xHCI regs,
-* since it will be requested by the xhci-plat driver.
-*/
-   regs = devm_ioremap_resource(dev, res);
-   if (IS_ERR(regs))
-   return PTR_ERR(regs);
-
spin_lock_init(&dwc->lock);
platform_set_drvdata(pdev, dwc);
 
-   dwc->regs   = regs;
-   dwc->regs_size  = resource_size(res);
-
dev->dma_mask   = dev->parent->dma_mask;
dev->dma_parms  = dev->parent->dma_parms;
dma_set_coherent_mask(dev, dev->parent->coherent_dma_mask);
-- 
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 1/1] i2c: s3c2410: Remove class based instantiation

[Wolfram Sang]

On Tue, Jun 03, 2014 at 02:30:22PM +0530, Sachin Kamat wrote:
> With multiplatform support enabled for Exynos, class based
> instantiation causes a boot time delay due to I2C_CLASS_HWMON
> triggered probe. Since class based instantiation has been
> deprecated since some time now, remove it for Samsung I2C driver.
> 
> Signed-off-by: Sachin Kamat 
> Cc: Olof Johansson 

In my book, not long enough. I suggest I will take care of the removal.
I'll do it for all class deprecating drivers.



signature.asc
Description: Digital signature

[PATCH] serial: samsung: fix typo in debug code

[Arnd Bergmann]

commit e4ac92df2791 ("serial: samsung: Neaten dbg uses") introduced
a regression in the conversion from vsprintf to vsnprintf.

This fixes the build error by passing the correct variable name.

Signed-off-by: Arnd Bergmann 
Cc: Joe Perches 
Cc: Greg Kroah-Hartman 
Cc: Doug Anderson 
Cc: Kukjin Kim 

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 3293377..c1d3ebd 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -66,7 +66,7 @@ static void dbg(const char *fmt, ...)
char buff[256];
 
va_start(va, fmt);
-   vscnprintf(buff, sizeof(buf), fmt, va);
+   vscnprintf(buff, sizeof(buff), fmt, va);
va_end(va);
 
printascii(buff);

--
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] ASoC: free jack GPIOs before the sound card is freed

[Mark Brown]

On Fri, May 30, 2014 at 12:42:57PM -0600, Stephen Warren wrote:
> From: Stephen Warren 
> 
> This is the same change as commit fb6b8e71448a "ASoC: tegra: free jack
> GPIOs before the sound card is freed", but applied to all other ASoC
> machine drivers where code inspection indicates the same problem exists.

Applied, thanks.


signature.asc
Description: Digital signature

[PATCH 1/1] i2c: s3c2410: Remove class based instantiation

[Sachin Kamat]

With multiplatform support enabled for Exynos, class based
instantiation causes a boot time delay due to I2C_CLASS_HWMON
triggered probe. Since class based instantiation has been
deprecated since some time now, remove it for Samsung I2C driver.

Signed-off-by: Sachin Kamat 
Cc: Olof Johansson 
---
 drivers/i2c/busses/i2c-s3c2410.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index bb3a9964f7e0..6f1706cdd9ba 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -1135,7 +1135,6 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
i2c->adap.owner   = THIS_MODULE;
i2c->adap.algo= &s3c24xx_i2c_algorithm;
i2c->adap.retries = 2;
-   i2c->adap.class   = I2C_CLASS_HWMON | I2C_CLASS_SPD | 
I2C_CLASS_DEPRECATED;
i2c->tx_setup = 50;
 
init_waitqueue_head(&i2c->wait);
-- 
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