Re: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC 4.5
On 24 November 2011 11:43, Subhash Jadavani wrote:
> Hi Girish,
>
>> -Original Message-
>> From: Girish K S [mailto:girish.shivananja...@linaro.org]
>> Sent: Monday, November 21, 2011 4:12 PM
>> To: Subhash Jadavani
>> Cc: linux-...@vger.kernel.org; c...@laptop.org; patc...@linaro.org;
>> linux-samsung-soc@vger.kernel.org
>> Subject: Re: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC
>> 4.5
>>
>> On 19 November 2011 00:29, Subhash Jadavani
>> wrote:
>> > Hi Girish,
>> >
>> >> -Original Message-
>> >> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
>> >> ow...@vger.kernel.org] On Behalf Of Girish K S
>> >> Sent: Wednesday, October 26, 2011 10:30 AM
>> >> To: linux-...@vger.kernel.org
>> >> Cc: c...@laptop.org; patc...@linaro.org; linux-samsung-
>> >> s...@vger.kernel.org; Girish K S
>> >> Subject: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC
>> 4.5
>> >>
>> >> This patch adds the support of the HS200 bus speed for eMMC 4.5
>> >> devices.
>> >> The eMMC 4.5 devices have support for 200MHz bus speed.The mmc core
>> and
>> >> host modules have been touched to add support for this module.
>> >>
>> >> It is necessary to know the card type in the sdhci.c file to add
>> >> support
>> >> for eMMC tuning function. So card.h file is included to import the
>> card
>> >> data structure.
>> >
>> > We don't need to know the card type in the host controller driver if
>> we pass
>> > the command opcode as the 2nd argument to execute_tuning() ops.
>> Command
>> > opcode can have have either CMD19 or CMD21 as it's value depending on
>> the
>> > card type (whether it's SD3.0 card or eMMC4.5 card).
>
> Can you see if we can implement this?
I have considered this and made the patch
>
>> >
>> >
>> >>
>> >> cc: Chris Ball
>> >> Signed-off-by: Girish K S
>> >> ---
>> >> Changes in v4:
>> >> Rebased onto chris-mmc/mmc-next branch. This patch is
>> >> successfully
>> >> applied on commit with id
>> >> de022ed3fdc14808299b2fa66dbb1ed5ab921912.
>> >> Changes in v3:
>> >> In the previous commits of chris-mmc/mmc-next branch, the
>> patch
>> >> with
>> >> commit id (c0f22a2c92e357e7cb3988b0b13034d70b7461f9) defines
>> >> caps2 for
>> >> more capabilities. This patch version deletes the member
>> >> ext_caps(created
>> >> in my earlier patch) from struct mmc_host and reuses already
>> >> accepted
>> >> caps2 member.
>> >> Changes in v2:
>> >> Rebased to latest chris-mmc/mmc-next branch. Resolved
>> indentation
>> >> problems identified in review. This patch has to be applied
>> >> before
>> >> the patch released for modifying the printk messages.
>> >> Changes in v1:
>> >> Case statements in switch that produce same result have
>> >> been combined to reduce repeated assignments.
>> >> patch recreated after rebase to chris balls mmc-next branch.
>> >>
>> >> drivers/mmc/core/bus.c | 3 +-
>> >> drivers/mmc/core/mmc.c | 92
>> >>
>> >> drivers/mmc/host/sdhci.c | 36 +++---
>> >> include/linux/mmc/card.h | 3 +
>> >> include/linux/mmc/host.h | 6 +++
>> >> include/linux/mmc/mmc.h | 8 +++-
>> >> include/linux/mmc/sdhci.h | 1 +
>> >> 7 files changed, 132 insertions(+), 17 deletions(-)
>> >>
>> >> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
>> >> index 46b6e84..2f82f6b 100644
>> >> --- a/drivers/mmc/core/bus.c
>> >> +++ b/drivers/mmc/core/bus.c
>> >> @@ -301,10 +301,11 @@ int mmc_add_card(struct mmc_card *card)
>> >> mmc_card_ddr_mode(card) ? "DDR " : "",
>> >> type);
>> >> } else {
>> >> - printk(KERN_INFO "%s: new %s%s%s card at address
>> %04x\n",
>> >> + pr_info("%s: new %s%s%s%s card at address %04x\n",
>> >> mmc_hostname(card->host),
>> >> mmc_sd_card_uhs(card) ? "ultra high speed " :
>> >> (mmc_card_highspeed(card) ? "high speed " :
>> ""),
>> >> + (mmc_card_hs200(card) ? "HS200 " : ""),
>> >> mmc_card_ddr_mode(card) ? "DDR " : "",
>> >> type, card->rca);
>> >> }
>> >> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> >> index 3627044..4db248c 100644
>> >> --- a/drivers/mmc/core/mmc.c
>> >> +++ b/drivers/mmc/core/mmc.c
>> >> @@ -285,6 +285,39 @@ static int mmc_read_ext_csd(struct mmc_card
>> *card,
>> >> u8 *ext_csd)
>> >> }
>> >> card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
>> >> switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
>> >> + case EXT_CSD_CARD_TYPE_SDR_200 |
>> >> + EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
>> >> + case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_8V |
>> >> + EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
>> >> + case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_2V |
>>
RE: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC 4.5
Hi Girish,
> -Original Message-
> From: Girish K S [mailto:girish.shivananja...@linaro.org]
> Sent: Monday, November 21, 2011 4:12 PM
> To: Subhash Jadavani
> Cc: linux-...@vger.kernel.org; c...@laptop.org; patc...@linaro.org;
> linux-samsung-soc@vger.kernel.org
> Subject: Re: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC
> 4.5
>
> On 19 November 2011 00:29, Subhash Jadavani
> wrote:
> > Hi Girish,
> >
> >> -Original Message-
> >> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> >> ow...@vger.kernel.org] On Behalf Of Girish K S
> >> Sent: Wednesday, October 26, 2011 10:30 AM
> >> To: linux-...@vger.kernel.org
> >> Cc: c...@laptop.org; patc...@linaro.org; linux-samsung-
> >> s...@vger.kernel.org; Girish K S
> >> Subject: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC
> 4.5
> >>
> >> This patch adds the support of the HS200 bus speed for eMMC 4.5
> >> devices.
> >> The eMMC 4.5 devices have support for 200MHz bus speed.The mmc core
> and
> >> host modules have been touched to add support for this module.
> >>
> >> It is necessary to know the card type in the sdhci.c file to add
> >> support
> >> for eMMC tuning function. So card.h file is included to import the
> card
> >> data structure.
> >
> > We don't need to know the card type in the host controller driver if
> we pass
> > the command opcode as the 2nd argument to execute_tuning() ops.
> Command
> > opcode can have have either CMD19 or CMD21 as it's value depending on
> the
> > card type (whether it's SD3.0 card or eMMC4.5 card).
Can you see if we can implement this?
> >
> >
> >>
> >> cc: Chris Ball
> >> Signed-off-by: Girish K S
> >> ---
> >> Changes in v4:
> >> Rebased onto chris-mmc/mmc-next branch. This patch is
> >> successfully
> >> applied on commit with id
> >> de022ed3fdc14808299b2fa66dbb1ed5ab921912.
> >> Changes in v3:
> >> In the previous commits of chris-mmc/mmc-next branch, the
> patch
> >> with
> >> commit id (c0f22a2c92e357e7cb3988b0b13034d70b7461f9) defines
> >> caps2 for
> >> more capabilities. This patch version deletes the member
> >> ext_caps(created
> >> in my earlier patch) from struct mmc_host and reuses already
> >> accepted
> >> caps2 member.
> >> Changes in v2:
> >> Rebased to latest chris-mmc/mmc-next branch. Resolved
> indentation
> >> problems identified in review. This patch has to be applied
> >> before
> >> the patch released for modifying the printk messages.
> >> Changes in v1:
> >> Case statements in switch that produce same result have
> >> been combined to reduce repeated assignments.
> >> patch recreated after rebase to chris balls mmc-next branch.
> >>
> >> drivers/mmc/core/bus.c | 3 +-
> >> drivers/mmc/core/mmc.c | 92
> >>
> >> drivers/mmc/host/sdhci.c | 36 +++---
> >> include/linux/mmc/card.h | 3 +
> >> include/linux/mmc/host.h | 6 +++
> >> include/linux/mmc/mmc.h | 8 +++-
> >> include/linux/mmc/sdhci.h | 1 +
> >> 7 files changed, 132 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
> >> index 46b6e84..2f82f6b 100644
> >> --- a/drivers/mmc/core/bus.c
> >> +++ b/drivers/mmc/core/bus.c
> >> @@ -301,10 +301,11 @@ int mmc_add_card(struct mmc_card *card)
> >> mmc_card_ddr_mode(card) ? "DDR " : "",
> >> type);
> >> } else {
> >> - printk(KERN_INFO "%s: new %s%s%s card at address
> %04x\n",
> >> + pr_info("%s: new %s%s%s%s card at address %04x\n",
> >> mmc_hostname(card->host),
> >> mmc_sd_card_uhs(card) ? "ultra high speed " :
> >> (mmc_card_highspeed(card) ? "high speed " :
> ""),
> >> + (mmc_card_hs200(card) ? "HS200 " : ""),
> >> mmc_card_ddr_mode(card) ? "DDR " : "",
> >> type, card->rca);
> >> }
> >> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> >> index 3627044..4db248c 100644
> >> --- a/drivers/mmc/core/mmc.c
> >> +++ b/drivers/mmc/core/mmc.c
> >> @@ -285,6 +285,39 @@ static int mmc_read_ext_csd(struct mmc_card
> *card,
> >> u8 *ext_csd)
> >> }
> >> card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
> >> switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
> >> + case EXT_CSD_CARD_TYPE_SDR_200 |
> >> + EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> >> + case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_8V |
> >> + EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> >> + case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_2V |
> >> + EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> >> + case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_52 |
> >> + EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> >> + card->ext
RE: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Koen Kooi
> Sent: Wednesday, November 23, 2011 8:51 PM
> To: Tony Lindgren
> Cc: Linus Walleij; Thomas Abraham; Nayak, Rajendra; linux-
> o...@vger.kernel.org; linaro-...@lists.linaro.org;
> linus.wall...@stericsson.com; linux-samsung-soc; devicetree-
> disc...@lists.ozlabs.org
> Subject: Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
>
>
> Op 22 nov. 2011, om 18:54 heeft Tony Lindgren het volgende geschreven:
>
> > * Linus Walleij [22 03:30]:
> >> On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> >> wrote:
> >>> On 17 November 2011 19:27, Linus Walleij
> wrote:
>
> Maybe I'm mistaken about the device tree ambitions, but
> I was sort of hoping that it would not contain too much
> custom magic numbers that need to be cross-referenced
> elsewhere ... or rather - the more understandable the device
> tree is, the more we win.
> >>>
> >>> Device tree is expected to describe the hardware. So to
> >>> cross-reference the hardware manual to understand device tree should
> >>> be fine I guess. For instance, GPIO numbers in dts would be written as
> >>> a numeric number and not a enum or other format. And by looking up the
> >>> manual, we understand the actual details of the GPIO pin.
> >>>
> >>> If dt-compiler had a option to support #define like in C, the numbers
> >>> could have been made more easier to understand. Like, 3 to mean
> >>> GPIO_PULL_UP in Exynos dts file.
> >>
> >> OK I think I get it now, so DT bindings shall really NOT be read
> >> by any of the pinctrl core, it is *supposed* to be all driver-specific.
> >> Then it makes perfect sense to have it as it is.
> >
> > Yes the driver nodes should describe in DT which pins to use:
> >
> >serial@1234 {
> >compatible = "8250";
> >reg = <0x1234 0x40>;
> >reg-shift = <2>;
> >interrupts = < 10 >;
> > pins = "uart1_rx", "uart1_tx";
> >};
> >
> > Note that we should use the actual signal names, not package specific
> > pad names. This way they have a high likelyhood to work for new packages
> > too by just mapping the signals to the new package.
>
> How would this handle the situation where you can mux a signal to multiple
> pins? IIRC omap3 and am335x can do funny stuff with the display pins like
> being able to map the blue bits to different pinblocks.
>
That's quite not true, in case of omap3 pins are labeled as R0-R7, B0-B7 and
G0-G7; what changes is pixel format.
AM335x LCDC is completely different IP altogether and spec doesn't map
Colors to pins. It barely maps bit0 from memory to pinX.
Now you call it as a standard or legacy or may be due to SGX software,
the pixel format we use is BGR (as in memory).
It is completely depends on how you interface the pins to LCD (considering)
Software support/requirement.
Thanks,
Vaibhav
> regards,
>
> Koen
--
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/6] ARM: exynos: Add AFTR mode cpuidle state on EXYNOS4210
Hi Amit,
On 22 November 2011 15:05, Amit Daniel Kachhap wrote:
>
> This patch adds support AFTR(ARM OFF TOP RUNNING) mode in
> cpuidle driver. L2 cache keeps their data in this mode.
> This patch ports the code to the latest interfaces to
> save/restore CPU state inclusive of CPU PM notifiers, l2
> resume and cpu_suspend/resume.
>
> Signed-off-by: Jaecheol Lee
> Signed-off-by: Lorenzo Pieralisi
> Signed-off-by: Amit Daniel Kachhap
> ---
> arch/arm/mach-exynos/cpuidle.c | 152
> ++-
> arch/arm/mach-exynos/include/mach/pmu.h | 2 +
> 2 files changed, 151 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
> index 21403c8..89afa93 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -12,15 +12,37 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
>
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
> + S5P_INFORM7 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
> + (S5P_VA_SYSRAM + 0x24) : S5P_INFORM0))
> +#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \
> + S5P_INFORM6 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
> + (S5P_VA_SYSRAM + 0x20) : S5P_INFORM1))
> +
> +#define S5P_CHECK_AFTR (samsung_rev() == EXYNOS4210_REV_1_0 ? \
> + 0xBAD0 : 0xFCBA0D10)
>
> static int exynos4_enter_idle(struct cpuidle_device *dev,
> struct cpuidle_driver *drv,
> int index);
> +static int exynos4_enter_lowpower(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv,
> + int index);
>
> static struct cpuidle_state exynos4_cpuidle_set[] = {
> [0] = {
> @@ -28,9 +50,17 @@ static struct cpuidle_state exynos4_cpuidle_set[] = {
> .exit_latency = 1,
> .target_residency = 10,
> .flags = CPUIDLE_FLAG_TIME_VALID,
> - .name = "IDLE",
> + .name = "C0",
> .desc = "ARM clock gating(WFI)",
> },
> + [1] = {
> + .enter = exynos4_enter_lowpower,
> + .exit_latency = 300,
> + .target_residency = 10,
> + .flags = CPUIDLE_FLAG_TIME_VALID,
> + .name = "C1",
> + .desc = "ARM power down",
> + },
> };
>
> static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
> @@ -40,9 +70,101 @@ static struct cpuidle_driver exynos4_idle_driver = {
> .owner = THIS_MODULE,
> };
>
> +/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
> +static void exynos4_set_wakeupmask(void)
> +{
> + __raw_writel(0xff3e, S5P_WAKEUP_MASK);
> +}
> +
> +static unsigned int g_pwr_ctrl, g_diag_reg;
> +
> +static void save_cpu_arch_register(void)
> +{
> + /*read power control register*/
> + asm("mrc p15, 0, %0, c15, c0, 0" : "=r"(g_pwr_ctrl) : : "cc");
> + /*read diagnostic register*/
> + asm("mrc p15, 0, %0, c15, c0, 1" : "=r"(g_diag_reg) : : "cc");
> + return;
> +}
> +
> +static void restore_cpu_arch_register(void)
> +{
> + /*write power control register*/
> + asm("mcr p15, 0, %0, c15, c0, 0" : : "r"(g_pwr_ctrl) : "cc");
> + /*write diagnostic register*/
> + asm("mcr p15, 0, %0, c15, c0, 1" : : "r"(g_diag_reg) : "cc");
> + return;
> +}
> +
> +static int idle_finisher(unsigned long flags)
> +{
> + cpu_do_idle();
> + return 1;
> +}
> +
> +static int exynos4_enter_core0_aftr(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv,
> + int index)
> +{
> + struct timeval before, after;
> + int idle_time;
> + unsigned long tmp;
> +
> + local_irq_disable();
> + do_gettimeofday(&before);
> +
> + exynos4_set_wakeupmask();
> +
> + /* Set value of power down register for aftr mode */
> + exynos4_sys_powerdown_conf(SYS_AFTR);
> +
> + __raw_writel(BSYM(virt_to_phys(s3c_cpu_resume)),
> + REG_DIRECTGO_ADDR);
> + __raw_writel(S5P_CHECK_AFTR, REG_DIRECTGO_FLAG);
> +
> + save_cpu_arch_register();
> +
> + /* Setting Central Sequence Register for power down mode */
> + tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
> + tmp &= ~S5P_CENTRAL_LOWPWR_CFG;
> + __raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
> +
> + cpu_pm_enter();
> + c
Re: [GIT PULL] Samsung fixes for v3.2
On Thu, Nov 24, 2011 at 6:15 AM, Arnd Bergmann wrote:
> On Monday 21 November 2011, Kukjin Kim wrote:
>> Please pull samsung-fixes for v3.2 from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> samsung-fixes
>>
>> This includes fix of inclusion header.
>> If any problems, please let me know.
>>
>
> Pulled, thanks!
>
> On Monday 21 November 2011, Kyungmin Park wrote:
>> Don't you fix the mct compiler error if LOCAL_TIMERS are not defined?
>>
>> arch/arm/mach-exynos/mct.c: In function 'exynos4_timer_resources':
>> arch/arm/mach-exynos/mct.c:451: error: 'exynos4_mct_tick_isr'
>> undeclared (first use in this function)
>> arch/arm/mach-exynos/mct.c:451: error: (Each undeclared identifier is
>> reported only once
>> arch/arm/mach-exynos/mct.c:451: error: for each function it appears in.)
>> make[1]: *** [arch/arm/mach-exynos/mct.o] Error 1
>
> Has a patch been posted for this?
>
> Arnd
There was a discussion about this and a patch seemed to be ready
although I don't know where:
---[quoting: "Re: [PATCH 1/2] ARM: EXYNOS4: convert MCT to percpu
interrupt API" from linux-arm-ker...@lists.infradead.org]---
On 10/11/11 23:33, MyungJoo Ham wrote:
> On Thu, Nov 10, 2011 at 6:43 PM, Marc Zyngier wrote:
>> On 10/11/11 02:40, MyungJoo Ham wrote:
>>> On Thu, Nov 3, 2011 at 2:30 AM, Marc Zyngier wrote:
MCT recently gained per cpu interrupts, and missed the fact that
ARM has moved to a genirq based implementation.
This patch converts the driver to the new API.
Boot tested on Origen.
Cc: Kukjin Kim
Signed-off-by: Marc Zyngier
>>>
>>> There is one concern regarding the CONFIG_LOCAL_TIMER.
>>>
>>> []
#endif /* CONFIG_LOCAL_TIMERS */
static void __init exynos4_timer_resources(void)
@@ -438,6 +442,16 @@ static void __init exynos4_timer_resources(void)
mct_clk = clk_get(NULL, "xtal");
clk_rate = clk_get_rate(mct_clk);
+
+ if (mct_int_type == MCT_INT_PPI) {
+ int err;
+
+ err = request_percpu_irq(IRQ_MCT_LOCALTIMER,
+exynos4_mct_tick_isr, "MCT",
+&percpu_mct_tick);
+ WARN(err, "MCT: can't request IRQ %d (%d)\n",
+IRQ_MCT_LOCALTIMER, err);
+ }
}
>>>
>>> You've added exynos4_mct_tick_isr, which is defined in
>>> CONFIG_LOCAL_TIMER section, in the place that is compiled without
>>> CONFIG_LOCAL_TIMER.
>>> I guess we are going to stop supporting LOCAL_TIMER in Exynos later
>>> and this could be a problem with it.
>>
>> Yup, this is a problem. It probably means we need to #ifdef that chink
>> as well. I'm not sure I get your remark about not supporting LOCAL_TIMER
>> though. Are you planning to move away from the LOCAL_TIMER infrastructure?
>
> Yes, we may need to #ifdef that block.
> And yes, for the Exynos series, I'll need to double check; however, I
> think we are planning to move away from the LOCAL_TIMER for MCT.
I have patches for this already.
- Hide quoted text -
M.
--
Jazz is not dead. It just smells funny...
--
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
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: [GIT PULL] Samsung fixes for v3.2
On Monday 21 November 2011, Kukjin Kim wrote: > Please pull samsung-fixes for v3.2 from: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > samsung-fixes > > This includes fix of inclusion header. > If any problems, please let me know. > Pulled, thanks! On Monday 21 November 2011, Kyungmin Park wrote: > Don't you fix the mct compiler error if LOCAL_TIMERS are not defined? > > arch/arm/mach-exynos/mct.c: In function 'exynos4_timer_resources': > arch/arm/mach-exynos/mct.c:451: error: 'exynos4_mct_tick_isr' > undeclared (first use in this function) > arch/arm/mach-exynos/mct.c:451: error: (Each undeclared identifier is > reported only once > arch/arm/mach-exynos/mct.c:451: error: for each function it appears in.) > make[1]: *** [arch/arm/mach-exynos/mct.o] Error 1 Has a patch been posted for this? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
Op 22 nov. 2011, om 18:54 heeft Tony Lindgren het volgende geschreven:
> * Linus Walleij [22 03:30]:
>> On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
>> wrote:
>>> On 17 November 2011 19:27, Linus Walleij wrote:
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
>>>
>>> Device tree is expected to describe the hardware. So to
>>> cross-reference the hardware manual to understand device tree should
>>> be fine I guess. For instance, GPIO numbers in dts would be written as
>>> a numeric number and not a enum or other format. And by looking up the
>>> manual, we understand the actual details of the GPIO pin.
>>>
>>> If dt-compiler had a option to support #define like in C, the numbers
>>> could have been made more easier to understand. Like, 3 to mean
>>> GPIO_PULL_UP in Exynos dts file.
>>
>> OK I think I get it now, so DT bindings shall really NOT be read
>> by any of the pinctrl core, it is *supposed* to be all driver-specific.
>> Then it makes perfect sense to have it as it is.
>
> Yes the driver nodes should describe in DT which pins to use:
>
>serial@1234 {
>compatible = "8250";
>reg = <0x1234 0x40>;
>reg-shift = <2>;
>interrupts = < 10 >;
> pins = "uart1_rx", "uart1_tx";
>};
>
> Note that we should use the actual signal names, not package specific
> pad names. This way they have a high likelyhood to work for new packages
> too by just mapping the signals to the new package.
How would this handle the situation where you can mux a signal to multiple
pins? IIRC omap3 and am335x can do funny stuff with the display pins like being
able to map the blue bits to different pinblocks.
regards,
Koen
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PATCH v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On Fri, Nov 18, 2011 at 06:47:28PM +0900, KyongHo Cho wrote: > Changes since v6: > - Totally rewrite exynos_iommu_map() and exynos_iommu_unmap() according > to the change in iommu_map() and iommu_unmap(). > - Change special slab for Lv2 page table to kmalloc(). Okay, the driver looks good to me now. If there are no further objections I am going to merge it for 3.3. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On 16:28 Tue 22 Nov , Stephen Warren wrote:
> Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM:
> > * Linus Walleij [22 03:30]:
> > > On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> > > wrote:
> > > > On 17 November 2011 19:27, Linus Walleij
> > > > wrote:
> > > >>
> > > >> Maybe I'm mistaken about the device tree ambitions, but
> > > >> I was sort of hoping that it would not contain too much
> > > >> custom magic numbers that need to be cross-referenced
> > > >> elsewhere ... or rather - the more understandable the device
> > > >> tree is, the more we win.
> > > >
> > > > Device tree is expected to describe the hardware. So to
> > > > cross-reference the hardware manual to understand device tree should
> > > > be fine I guess. For instance, GPIO numbers in dts would be written as
> > > > a numeric number and not a enum or other format. And by looking up the
> > > > manual, we understand the actual details of the GPIO pin.
> > > >
> > > > If dt-compiler had a option to support #define like in C, the numbers
> > > > could have been made more easier to understand. Like, 3 to mean
> > > > GPIO_PULL_UP in Exynos dts file.
> > >
> > > OK I think I get it now, so DT bindings shall really NOT be read
> > > by any of the pinctrl core, it is *supposed* to be all driver-specific.
> > > Then it makes perfect sense to have it as it is.
> >
> > Yes the driver nodes should describe in DT which pins to use:
> >
> > serial@1234 {
> > compatible = "8250";
> > reg = <0x1234 0x40>;
> > reg-shift = <2>;
> > interrupts = < 10 >;
> > pins = "uart1_rx", "uart1_tx";
> > };
>
> Sorry to jump in late here, but I wasn't aware of this thread.
>
> I don't necessarily agree with that. Describing the HW doesn't necessarily
> mean that each device needs to describe what pinmux pins it uses; one
> could quite easily have the pinmux describe what settings the various
> pins should have and which drivers will use those pins. That would map
> very well to the pinctrl subsystem's mapping table, and at least Tegra's
> existing pinmux tables, which are both just a big array of settings which
> end up getting provided to drivers.
>
> I'll try and track down the rest of this thread and catch up though...
I agreee here
as example on at91 I try to found a good way to let the macb driver to ask the
pin configuration
so in my mind i do not need put all pins in each board but in the dtsi and
then in the drivers just said
pins = "mii";
or
pins = "rmii";
or if I want to use the alternative config
pins = "mii_alt";
or
pins = "rmii_alt";
and then in the dtsi I describe the pin used for those configs
which is soc specifific not board
Best Regards,
J.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/6] ARM: s5p: remove useless churn in sleep.S
On Tue, Nov 22, 2011 at 3:18 PM, Russell King - ARM Linux wrote: > On Tue, Nov 22, 2011 at 03:05:28PM +0530, Amit Daniel Kachhap wrote: >> This patch cleans up sleep code in preparation for L2 resume code >> and hotplug functions > > I wonder whether anyone read the comments in this file before they > changed the section for the code. > /* > * sleep magic, to allow the bootloader to check for an valid > * image to resume to. Must be the first word before the > * s3c_cpu_resume entry. > */ Ok,This looks like an error. Thanks for pointing this out. Will put the entire section into data. > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
