Re: [PATCH] pinctrl: add a gpio and pinctrl driver for samsung io-pad controllers
On Tue, Nov 15, 2011 at 9:06 PM, Thomas Abraham wrote: > This driver supports gpio, pinctrl and pinmux functionality. At present, all > the > possible pin groups and pin functions have not been added. This driver is > designed to be reusable across all Samsung SoC's and when this implemtation is > complete, the gpio driver in driver/gpio for samsung platforms can be phased > out. > Features like GPIO interrupt support and pin-config support are yet to be > added. I would prefer if we have this driver on ice or in the drivers/staging/* hierarchy until it can completely replace the GPIO driver and the platform variant. I am aware that you need more support from the pinctrl subsystem before you can do this, I'm working on the things I can provide... Overall the driver looks good! Pretty massive with three controller instances, but it looks all manageable. Yours, Linus Walleij -- 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: core: Add packed command for eMMC4.5 device
Sahitya Tummala wrote:
> Hi,
>
> On 10/27/2011 4:24 PM, Seungwon Jeon wrote:
> >
> > +static int mmc_blk_packed_err_check(struct mmc_card *card,
> > +struct mmc_async_req *areq)
> > +{
> > + struct mmc_queue_req *mq_mrq = container_of(areq, struct mmc_queue_req,
> > + mmc_active);
> > + int err, check, status;
> > + u8 ext_csd[512];
> > +
> > + check = mmc_blk_err_check(card, areq);
> > +
> > + if (check == MMC_BLK_SUCCESS)
> > + return check;
> > +
> > + if (check == MMC_BLK_PARTIAL) {
> > + err = get_card_status(card,&status, 0);
> > + if (err)
> > + return MMC_BLK_ABORT;
> > +
> > + if (status& R1_EXP_EVENT) {
> > + err = mmc_send_ext_csd(card, ext_csd);
> > + if (err)
> > + return MMC_BLK_ABORT;
> > +
> > + if ((ext_csd[EXT_CSD_EXP_EVENTS_STATUS + 0]&
> > + EXT_CSD_PACKED_FAILURE)&&
> > + (ext_csd[EXT_CSD_PACKED_CMD_STATUS]&
> > +EXT_CSD_PACKED_GENERIC_ERROR)) {
> > + if (ext_csd[EXT_CSD_PACKED_CMD_STATUS]&
> > + EXT_CSD_PACKED_INDEXED_ERROR) {
> > + /* Make be 0-based */
> > + mq_mrq->packed_fail_idx =
> > +
> > ext_csd[EXT_CSD_PACKED_FAILURE_INDEX] - 1;
> > + return MMC_BLK_PARTIAL;
> > + } else {
> > + return MMC_BLK_RETRY;
> > + }
> > + }
> > + } else {
> > + return MMC_BLK_RETRY;
> > + }
> > + }
> > +
> > + if (check != MMC_BLK_ABORT)
> > + return MMC_BLK_RETRY;
> > + else
> > + return MMC_BLK_ABORT;
>
> The current code does not return other errors (MMC_BLK_CMD_ERR,
> MMC_BLK_ECC_ERR and MMC_BLK_DATA_ERR) returned by mmc_blk_err_check().
> Why not return check here?
Currently retry is taken in case of other errors.
But some case needs to be split.
>
> > +}
> > +
> > static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
> >struct mmc_card *card,
> >int disable_multi,
> > @@ -1126,6 +1187,207 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req
> > *mqrq,
> > mmc_queue_bounce_pre(mqrq);
> > }
> >
> > +static u8 mmc_blk_chk_packable(struct mmc_queue *mq, struct request *req)
> > +{
> > + struct request_queue *q = mq->queue;
> > + struct mmc_card *card = mq->card;
> > + struct request *cur = req, *next = NULL;
> > + struct mmc_blk_data *md = mq->data;
> > + bool en_rel_wr = card->ext_csd.rel_param& EXT_CSD_WR_REL_PARAM_EN;
> > + unsigned int req_sectors = 0, phys_segments = 0;
> > + unsigned int max_blk_count, max_phys_segs;
> > + u8 max_packed_rw = 0;
> > + u8 reqs = 0;
> > +
> > + if (!(md->flags& MMC_BLK_CMD23)&&
> > + !card->ext_csd.packed_event_en)
> > + goto no_packed;
> > +
> > + if (rq_data_dir(cur) == READ)
> > + max_packed_rw = card->ext_csd.max_packed_reads;
> > + else
> > + max_packed_rw = card->ext_csd.max_packed_writes;
> > +
> > + if (max_packed_rw == 0)
> > + goto no_packed;
> > +
> > + if (mmc_req_rel_wr(cur)&&
> > + (md->flags& MMC_BLK_REL_WR)&&
> > + !en_rel_wr) {
> > + goto no_packed;
> > + }
> > +
> > + max_blk_count = min(card->host->max_blk_count,
> > + card->host->max_req_size>> 9);
> > + max_phys_segs = queue_max_segments(q);
> > + req_sectors += blk_rq_sectors(cur);
> > + phys_segments += req->nr_phys_segments;
> > +
> > + if (rq_data_dir(cur) == WRITE) {
> > + req_sectors++;
> > + phys_segments++;
> > + }
> > +
> > + while (reqs< max_packed_rw - 1) {
>
> What if the number of requests exceeds the packed header size defined?
Currently not considered.
That case is maximum r/w depth from eMMC device is wrong, right?
It may not happen in practice. But the limit may need to restricted.
>
> > + next = blk_fetch_request(q);
> > + if (!next)
> > + break;
> > +
> > + if (rq_data_dir(cur) != rq_data_dir(next)) {
> > + blk_requeue_request(q, next);
> > + break;
> > + }
> > +
> > + if (mmc_req_rel_wr(next)&&
> > + (md->flags& MMC_BLK_REL_WR)&&
> > + !en_rel_wr) {
> > + blk_requeue_request(q, next);
> > + break;
> > + }
> > +
> > + req_sectors += blk_rq_sectors(next);
> > + if (req_sectors> max_blk_count
Re: [PATCH 1/4] ARM: exynos4: Add support for AFTR mode cpuidle state
On 11 November 2011 13:03, MyungJoo Ham wrote: > On Sat, Nov 5, 2011 at 2:03 AM, wrote: >> From: Amit Daniel Kachhap >> >> This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in >> cpuidle driver for EXYNOS4210. 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 >> --- > [] >> +#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \ >> + S5P_INFORM7 : (S5P_VA_SYSRAM + 0x24)) >> +#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \ >> + S5P_INFORM6 : (S5P_VA_SYSRAM + 0x20)) >> > [] >> + >> + __raw_writel(BSYM(virt_to_phys(s3c_cpu_resume)), >> + REG_DIRECTGO_ADDR); >> + __raw_writel(0xfcba0d10, REG_DIRECTGO_FLAG); >> + >> return 0; > > Hello, > > > Why are you using INFORM6 and 7 registers in order to save resume > address and power-mode flags? > > INFORM0 and 1 have been used in pm.c for the exactly same purpose. > Please use the same registers in cpuidle.c as well. > > The same part in bootloader (IPL) can handle whether it's > suspend-to-RAM or AFTR and the both modes are mutually exclusive and > you only need one value for resume PC. > > Therefore, you can keep the value at the same location, which is the > method we have been using. Hi, I tried using INFORM0 and INFORM1 in cpuidle and make it same as pm.c. But this doesnt work. Looks like my irom fused code checks for the wakeup source and needs INFORM7 and INFORM6 for non sleep wakeups. My cpu version is S5PV310AH--0AH1113(Origen board). I suggest adding support for both type of wakeups(directly from irom and through bootloader). Thanks, Amit D > > Besides, the Exynos4210 chipmaker (S.LSI) has told that INFORM6 and 7 > registers are used by in-chip code (iROM or iRAM). > > > Cheers! > MyungJoo > > > > -- > 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: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On 17 November 2011 13:38, Linus Walleij wrote:
>> Linus,
>> Is there a plan to move even the data that exists in the pinmux
>> drivers today (including the function/pin-groups definition)
>> eventually to DT? Or is it just the 'mapping' data to map
>> devices to functions (that today is done from board files) which
>> alone will be moved?
>
> Not for the U300 driver, for the simple reason that it cannot
> use device tree. So both methods of providing the data need
> to be allowed - either as static data (the U300 driver does not
> even have platform data, the pin data is encoded in the driver
> itself since it's tied to U300 and not used for any other systems
> or variants) or as device tree lookups.
>
> That said I have no clue on how to make the DT bindings
> FTM, patches and suggestions welcome.
For now, the Samsung GPIO, Pinconfig and Pinmux information is
represented in device tree as listed below.
i2c@1C004000 {
compatible = "...";
reg = <0x... 0x..>;
gpios = <&gpa0 2 2 3 0>,
<&gpa0 3 2 3 0>;
...
};
The format of the gpio specifier is
<[Pad Controller phandle] [pin number within the controller] [Pin Mux
Function] [Pull Up/Down] [Drive Strength]>
>From a perspective of writing a 'gpios' property for a device node,
this is quite simple. Looking up the hardware manual of the SoC can
provide all the values that should be used in the gpio specifier.
The GPIO/PinCtrl driver can provide a translate function that picks up
the values for the gpio specifier and writes the same value to the
pad-controller registers. But, this a deviation from the existing
pinctrl subsystem code which mainly relies on name of the pin-group
and pin-function.
Does this seem to be a feasible option for specifying
gpio/pinconfig/pinmux dt bindings?
Thanks.
Thomas.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC 4.5
On 17 November 2011 11:06, Subhash Jadavani wrote:
> Hi Girish,
>
>> -Original Message-
>> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
>> ow...@vger.kernel.org] On Behalf Of Sahitya Tummala
>> Sent: Tuesday, November 08, 2011 2:10 PM
>> To: Girish K S
>> 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
>>
>> Hi Girish,
>>
>> On 10/26/2011 10:29 AM, Girish K S wrote:
>> > 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.
>> >
>> > 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_csd.hs_max_dtr = 2;
>> > + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
>> > + break;
>> > + case EXT_CSD_CARD_TYPE_SDR_1_2V |
>> > + EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
>> > + case EXT_CSD_CARD_TYPE_SDR_1_2V | EXT_CSD_CARD_TYPE_DDR_1_8V |
>> > + EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
>> > + case EXT_CSD_CARD_TYPE_SDR_1_2V | EXT_CSD_CARD_TYPE_DDR_1_2V |
>> > + EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
>> > + case EXT_CSD_CARD_TYPE_SDR_1_2V | EXT_CSD_CARD_TYPE_DDR_52 |
>> > + EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
>> > + card->ext_csd.hs_max_dtr = 2;
>> > + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_2V;
>> > +
RE: [PATCH 2/2] mmc: core: Support packed command for eMMC4.5 device
> Maya Erez wrote:
>> >> >> >> >> > + phys_segments += next->nr_phys_segments;
>> >> >> >> >> > + if (phys_segments > max_phys_segs) {
>> >> >> >> >> > + blk_requeue_request(q, next);
>> >> >> >> >> > + break;
>> >> >> >> >> > + }
>> >> >> >> >> I mentioned this before - if the next request is not
>> packable
>> >> and
>> >> >> >> requeued,
>> >> >> >> >> blk_fetch_request will retrieve it again and this while loop
>> >> will
>> >> >> never terminate.
>> >> >> >> >>
>> >> >> >> > If next request is not packable, it is requeued and 'break'
>> >> >> terminates
>> >> >> >> this loop.
>> >> >> >> > So it not infinite.
>> >> >> >> Right !! But that doesn't help finding the commands that are
>> >> packable.
>> >> >> Ideally, you'd need to pack all neighbouring requests into one
>> packed
>> >> >> command.
>> >> >> >> The way CFQ works, it is not necessary that the fetch would
>> return
>> >> all
>> >> >> outstanding
>> >> >> >> requests that are packable (unless you invoke a forced
>> dispatch)
>> >> It
>> >> >> would be good to see some numbers on the number of pack hits /
>> >> >> misses
>> >> >> >> that
>> >> >> >> you would encounter with this logic, on a typical usecase.
>> >> >> > Is it considered only for CFQ scheduler? How about other I/O
>> >> scheduler?
>> >> >> If all requests are drained from scheduler queue forcedly,
>> >> >> > the number of candidate to be packed can be increased.
>> >> >> > However we may lose the unique CFQ's strength and MMC D/D may
>> take
>> >> the
>> >> >> CFQ's duty.
>> >> >> > Basically, this patch accommodates the origin order requests
>> from
>> >> I/O
>> >> >> scheduler.
>> >> >> >
>> >> >>
>> >> >> In order to better utilize the packed commands feature and achieve
>> >> the
>> >> >> best performance improvements I think that the command packing
>> should
>> >> be
>> >> >> done in the block layer, according to the scheduler policy.
>> >> >> That is, the scheduler should be aware of the capability of the
>> >> device to
>> >> >> receive a request list and its constrains (such as maximum number
>> of
>> >> >> requests, max number of sectors etc) and use this information as a
>> >> factor
>> >> >> to its algorithm.
>> >> >> This way you keep the decision making in the hands of the
>> scheduler
>> >> while
>> >> >> the MMC layer will only have to send this list as a packed
>> command.
>> >> >>
>> >> > Yes, it would be another interesting approach.
>> >> > Command packing you mentioned means gathering request among same
>> >> direction(read/write)?
>> >> > Currently I/O scheduler may know device constrains which MMC driver
>> >> informs
>> >> > with the exception of order information for packed command.
>> >> > But I think the dependency of I/O scheduler may be able to come up.
>> >> > How can MMC layer treat packed command with I/O scheduler which
>> >> doesn't support this?
>> >>
>> >> The very act of packing presumes some sorting and re-ordering at the
>> >> I/O scheduler level.
>> >> When no such sorting is done (ex. noop), MMC should resort to
>> >> non-packed execution, respecting the system configuration choice.
>> >>
>> >> Looking deeper into this, I think a better approach would be to set
>> >> the prep_rq_fn of the request_queue, with a custom mmc function that
>> >> decides if the requests are packable or not, and return a
>> >> BLKPREP_DEFER for those that can't be packed.
>> >
>> > MMC layer anticipates the favorable requests for packing from I/O
>> > scheduler.
>> > Obviously request order from I/O scheduler might be poor for packing
>> and
>> > requests can't be packed.
>> > But that doesn't mean mmc layer need to wait a better pack-case.
>> > BLKPREP_DEFER may give rise to I/O latency. Top of request will be
>> > deferred next time.
>> > If request can't be packed, it'd rather be sent at once than delayed
>> > by returning a BLKPREP_DEFER for better responsiveness.
>> >
>> > Thanks.
>> > Seungwon Jeon.
>> The decision whether a request is packable or not should not be made per
>> request, therefore I don't see the need for using req_prep_fn. The MMC
>> layer can peek each request and decide if to pack it or not when
>> preparing
>> the packed list (as suggested in this patch). The scheduler changes will
>> improve the probability of getting a list that can be packed.
>> My suggestion for the scheduler change is:
>> The block layer will be notified of the packing limits via new queue
>> limits (in blk-settings). We can make it generic to allow all kinds of
>> requests lists. Example for the new queue limits can be:
>> Is_reqs_list_supported
>> Max_num_of_read_reqs_in_list
>> Max_num_of_write_reqs_in_list
>> max_blk_cnt_in_list
>> Is_list_interleaved (optional - to support read and write requests to be
>> linked together, not the case for eMMC4.5)
>> The scheduler, that will have all the required info in the queue limits,
>> will be able to decide which requests can be in the
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham
wrote:
> For now, the Samsung GPIO, Pinconfig and Pinmux information is
> represented in device tree as listed below.
Does this mean that the understanding of this format is merged into
the mainline kernel drivers or is it keps out-of-tree?
> i2c@1C004000 {
> compatible = "...";
> reg = <0x... 0x..>;
> gpios = <&gpa0 2 2 3 0>,
> <&gpa0 3 2 3 0>;
> ...
> };
>
> The format of the gpio specifier is
> <[Pad Controller phandle] [pin number within the controller] [Pin Mux
> Function] [Pull Up/Down] [Drive Strength]>
>
> From a perspective of writing a 'gpios' property for a device node,
> this is quite simple. Looking up the hardware manual of the SoC can
> provide all the values that should be used in the gpio specifier.
That may not be as simple as it seems if all you have is the
device tree and no manual, but I get the picture.
> The GPIO/PinCtrl driver can provide a translate function that picks up
> the values for the gpio specifier and writes the same value to the
> pad-controller registers. But, this a deviation from the existing
> pinctrl subsystem code which mainly relies on name of the pin-group
> and pin-function.
>
> Does this seem to be a feasible option for specifying
> gpio/pinconfig/pinmux dt bindings?
I would prefer the above to use the nice generic enums from the
pin control subsystem's pinmux and pinconf properties in the
end so the device tree on its own is understandable without
any manual whatsoever, but we'll see about that.
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.
Thanks,
Linus Walleij
--
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/3] Support Samsung S5P OHCI device and driver
On Tue, Nov 15, 2011 at 06:49:58AM +, Jingoo Han wrote: > Hello. > > This patch series adds USB OHCI device and initial driver for Samsung > S5P SoCs and is based from Linux 3.2-rc1. I have tested on SMDKV310 board > using EXYNOS4. This is to be sent through some arm tree, not the usb tree, right? thanks, greg k-h -- 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: s5p tree moved back to kernel.org
Hi, On Thu, 17 Nov 2011 09:00:30 +0900 Kukjin Kim wrote: > > Could you please change my tree to following? > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > for-next I have switched to that. > If any problems, please let me know. The tree on kernel.org appears to have not been updated for the fix that appeared overnight. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpVVLN1990kX.pgp Description: PGP signature
Re: [PATCH 1/4] ARM: exynos4: Add support for AFTR mode cpuidle state
On Thu, Nov 17, 2011 at 8:22 PM, Amit Kachhap wrote: > On 11 November 2011 13:03, MyungJoo Ham wrote: >> On Sat, Nov 5, 2011 at 2:03 AM, wrote: >>> From: Amit Daniel Kachhap >>> >>> This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in >>> cpuidle driver for EXYNOS4210. 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 >>> --- >> [] >>> +#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \ >>> + S5P_INFORM7 : (S5P_VA_SYSRAM + 0x24)) >>> +#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \ >>> + S5P_INFORM6 : (S5P_VA_SYSRAM + 0x20)) >>> >> [] >>> + >>> + __raw_writel(BSYM(virt_to_phys(s3c_cpu_resume)), >>> + REG_DIRECTGO_ADDR); >>> + __raw_writel(0xfcba0d10, REG_DIRECTGO_FLAG); >>> + >>> return 0; >> >> Hello, >> >> >> Why are you using INFORM6 and 7 registers in order to save resume >> address and power-mode flags? >> >> INFORM0 and 1 have been used in pm.c for the exactly same purpose. >> Please use the same registers in cpuidle.c as well. >> >> The same part in bootloader (IPL) can handle whether it's >> suspend-to-RAM or AFTR and the both modes are mutually exclusive and >> you only need one value for resume PC. >> >> Therefore, you can keep the value at the same location, which is the >> method we have been using. > Hi, > > I tried using INFORM0 and INFORM1 in cpuidle and make it same as pm.c. > But this doesnt work. Looks like my irom fused code checks for the > wakeup source and needs INFORM7 and INFORM6 for non sleep wakeups. My > cpu version is S5PV310AH--0AH1113(Origen board). > I suggest adding support for both type of wakeups(directly from irom > and through bootloader). > Hello Amit, Have you checked the part that checks flags for AFTR mode and Suspend-to-RAM in IPL? If your code is checking AFTR flags with INFORM6/7 and PM flags with INFORM0/1, that is terribly wrong as those two modes are mutually exclusive and are very similar in terms of IPL codes. Also, the IPL-bootloader code runs in IRAM where CPU determines whether to continue to boot or jump to resume address of suspend-to-RAM or deepidle (AFTR/LPA/...). If yours works with INFORM0/1 for PM, it should work with INFORM0/1 in AFTR as well if your (S/W loadable) IPL code is correct and INFORM6/7 is not touched regardless of how your IROM code is written. Please check your IPL code and try to let AFTR use the same address with PM. There is no reason to use another INFORM registers for AFTR only. Please note that pm-related IPL code is not in ROM, but loaded by ROM part of IPL to RAM from a storage. To jc.lee, Could you please check whether your IPL code checks for INFORM0/1 for both PM and AFTR or INFORM0/1 for PM and INFORM6/7 for AFTR? If the latter is what your IPL does, then, how does it react when both INFORM0/1 and INFORM6/7 are set for both PM and AFTR? The IPL code we have uses INFORM0/1 for both PM and AFTR/LPA. Cheers! MyungJoo > Thanks, > Amit D >> >> Besides, the Exynos4210 chipmaker (S.LSI) has told that INFORM6 and 7 >> registers are used by in-chip code (iROM or iRAM). >> >> >> Cheers! >> MyungJoo >> >> >> >> -- >> MyungJoo Ham, Ph.D. >> Mobile Software Platform Lab, DMC Business, Samsung Electronics >> > -- 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
[PATCH V2 0/6] SPI platform device consolidation
SPI platform devices are defined in respective machine folder of Samsung S3C64XX and S5P series SoCs.This patchset moves S3C64XX and S5P series of SPI platform devices to a common place plat-samsung. This patchset also creates SPI setup files for GPIO configurations and platform data initialization. V2 Changes: Platform data initialized in a centralized setup file as suggested-by Mark Brown SPI Controller number is added in SPI controller defining structure. Padmavathi Venna (6): ARM: SAMSUNG: Consolidation of SPI platform devices to plat-samsung ARM: S3C64XX: Modified files for SPI consolidation work ARM: S5PC100: Modified files for SPI consolidation work. ARM: S5P64X0: Modified files for SPI consolidation work ARM: S5PV210: Modified files for SPI consolidation work The following patch make the corresponding SPI changes required for Wolfson Cragganmore S3C6410 variant. This patch is only build tested. ARM: S3C64XX: Modified according to SPI consolidation work. arch/arm/mach-s3c64xx/Kconfig|8 +- arch/arm/mach-s3c64xx/Makefile |2 +- arch/arm/mach-s3c64xx/dev-spi.c | 172 - arch/arm/mach-s3c64xx/include/mach/map.h |2 + arch/arm/mach-s3c64xx/setup-spi.c| 47 + arch/arm/mach-s5p64x0/Kconfig|7 +- arch/arm/mach-s5p64x0/Makefile |2 +- arch/arm/mach-s5p64x0/dev-spi.c | 218 - arch/arm/mach-s5p64x0/include/mach/map.h |3 + arch/arm/mach-s5p64x0/setup-spi.c| 57 ++ arch/arm/mach-s5pc100/Kconfig|5 + arch/arm/mach-s5pc100/Makefile |2 +- arch/arm/mach-s5pc100/dev-spi.c | 220 -- arch/arm/mach-s5pc100/include/mach/map.h |3 + arch/arm/mach-s5pc100/setup-spi.c| 68 +++ arch/arm/mach-s5pv210/Kconfig|5 + arch/arm/mach-s5pv210/Makefile |2 +- arch/arm/mach-s5pv210/dev-spi.c | 169 - arch/arm/mach-s5pv210/include/mach/map.h |2 + arch/arm/mach-s5pv210/setup-spi.c| 53 + arch/arm/plat-samsung/Kconfig| 14 ++- arch/arm/plat-samsung/devs.c | 106 +++ arch/arm/plat-samsung/include/plat/devs.h|8 +- arch/arm/plat-samsung/include/plat/s3c64xx-spi.h | 20 ++- 24 files changed, 395 insertions(+), 800 deletions(-) delete mode 100644 arch/arm/mach-s3c64xx/dev-spi.c create mode 100644 arch/arm/mach-s3c64xx/setup-spi.c delete mode 100644 arch/arm/mach-s5p64x0/dev-spi.c create mode 100644 arch/arm/mach-s5p64x0/setup-spi.c delete mode 100644 arch/arm/mach-s5pc100/dev-spi.c create mode 100644 arch/arm/mach-s5pc100/setup-spi.c delete mode 100644 arch/arm/mach-s5pv210/dev-spi.c create mode 100644 arch/arm/mach-s5pv210/setup-spi.c -- 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 1/6] ARM: SAMSUNG: Consolidation of SPI platform devices to plat-samsung
SPI platform device definitions consolidated from respective machine
folder to plat-samsung
Signed-off-by: Padmavathi Venna
---
arch/arm/mach-s3c64xx/Makefile |1 -
arch/arm/mach-s3c64xx/dev-spi.c | 172 -
arch/arm/mach-s5p64x0/Makefile |1 -
arch/arm/mach-s5p64x0/dev-spi.c | 218 -
arch/arm/mach-s5pc100/Makefile |1 -
arch/arm/mach-s5pc100/dev-spi.c | 220 --
arch/arm/mach-s5pv210/Makefile |1 -
arch/arm/mach-s5pv210/dev-spi.c | 169 -
arch/arm/plat-samsung/Kconfig| 14 ++-
arch/arm/plat-samsung/devs.c | 106 +++
arch/arm/plat-samsung/include/plat/devs.h|8 +-
arch/arm/plat-samsung/include/plat/s3c64xx-spi.h | 13 +-
12 files changed, 126 insertions(+), 798 deletions(-)
delete mode 100644 arch/arm/mach-s3c64xx/dev-spi.c
delete mode 100644 arch/arm/mach-s5p64x0/dev-spi.c
delete mode 100644 arch/arm/mach-s5pc100/dev-spi.c
delete mode 100644 arch/arm/mach-s5pv210/dev-spi.c
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index e32093c..d1d0f09 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -59,4 +59,3 @@ obj-$(CONFIG_MACH_WLF_CRAGG_6410) += mach-crag6410.o
mach-crag6410-module.o
obj-y += dev-uart.o
obj-y += dev-audio.o
-obj-$(CONFIG_S3C64XX_DEV_SPI) += dev-spi.o
diff --git a/arch/arm/mach-s3c64xx/dev-spi.c b/arch/arm/mach-s3c64xx/dev-spi.c
deleted file mode 100644
index 86fb130..000
--- a/arch/arm/mach-s3c64xx/dev-spi.c
+++ /dev/null
@@ -1,172 +0,0 @@
-/* linux/arch/arm/plat-s3c64xx/dev-spi.c
- *
- * Copyright (C) 2009 Samsung Electronics Ltd.
- * Jaswinder Singh
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-
-/* SPI Controller platform_devices */
-
-/* Since we emulate multi-cs capability, we do not touch the GPC-3,7.
- * The emulated CS is toggled by board specific mechanism, as it can
- * be either some immediate GPIO or some signal out of some other
- * chip in between ... or some yet another way.
- * We simply do not assume anything about CS.
- */
-static int s3c64xx_spi_cfg_gpio(struct platform_device *pdev)
-{
- unsigned int base;
-
- switch (pdev->id) {
- case 0:
- base = S3C64XX_GPC(0);
- break;
-
- case 1:
- base = S3C64XX_GPC(4);
- break;
-
- default:
- dev_err(&pdev->dev, "Invalid SPI Controller number!");
- return -EINVAL;
- }
-
- s3c_gpio_cfgall_range(base, 3,
- S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
-
- return 0;
-}
-
-static struct resource s3c64xx_spi0_resource[] = {
- [0] = {
- .start = S3C64XX_PA_SPI0,
- .end = S3C64XX_PA_SPI0 + 0x100 - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = DMACH_SPI0_TX,
- .end = DMACH_SPI0_TX,
- .flags = IORESOURCE_DMA,
- },
- [2] = {
- .start = DMACH_SPI0_RX,
- .end = DMACH_SPI0_RX,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- .start = IRQ_SPI0,
- .end = IRQ_SPI0,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct s3c64xx_spi_info s3c64xx_spi0_pdata = {
- .cfg_gpio = s3c64xx_spi_cfg_gpio,
- .fifo_lvl_mask = 0x7f,
- .rx_lvl_offset = 13,
- .tx_st_done = 21,
-};
-
-static u64 spi_dmamask = DMA_BIT_MASK(32);
-
-struct platform_device s3c64xx_device_spi0 = {
- .name = "s3c64xx-spi",
- .id = 0,
- .num_resources= ARRAY_SIZE(s3c64xx_spi0_resource),
- .resource = s3c64xx_spi0_resource,
- .dev = {
- .dma_mask = &spi_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = &s3c64xx_spi0_pdata,
- },
-};
-EXPORT_SYMBOL(s3c64xx_device_spi0);
-
-static struct resource s3c64xx_spi1_resource[] = {
- [0] = {
- .start = S3C64XX_PA_SPI1,
- .end = S3C64XX_PA_SPI1 + 0x100 - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = DMACH_SPI1_TX,
- .end = DMACH_SPI1_TX,
- .flags = IORESOURCE_DMA,
- },
- [2] = {
- .start = DMACH_SPI1_RX,
- .end = DMACH_SPI1_RX,
-
[PATCH V2 2/6] ARM: S3C64XX: Modified files for SPI consolidation work
As SPI platform devices are consolidated to plat-samsung, some
corresponding changes are required in the respective machine folder.
Setup files are added for SPI GPIO configurations and platform data
initialization.
Signed-off-by: Padmavathi Venna
---
arch/arm/mach-s3c64xx/Kconfig|5 ++
arch/arm/mach-s3c64xx/Makefile |1 +
arch/arm/mach-s3c64xx/include/mach/map.h |2 +
arch/arm/mach-s3c64xx/setup-spi.c| 47 ++
arch/arm/plat-samsung/include/plat/s3c64xx-spi.h |7 +++
5 files changed, 62 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s3c64xx/setup-spi.c
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 4d8c489..dea62bf 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -77,6 +77,11 @@ config S3C64XX_SETUP_SDHCI_GPIO
help
Common setup code for S3C64XX SDHCI GPIO configurations
+config S3C64XX_SETUP_SPI
+ bool
+ help
+Common setup code for SPI GPIO configurations
+
# S36400 Macchine support
config MACH_SMDK6400
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index d1d0f09..d7d9bb5 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_S3C64XX_SETUP_IDE) += setup-ide.o
obj-$(CONFIG_S3C64XX_SETUP_KEYPAD) += setup-keypad.o
obj-$(CONFIG_S3C64XX_SETUP_FB_24BPP) += setup-fb-24bpp.o
obj-$(CONFIG_S3C64XX_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
+obj-$(CONFIG_S3C64XX_SETUP_SPI) += setup-spi.o
# PM
diff --git a/arch/arm/mach-s3c64xx/include/mach/map.h
b/arch/arm/mach-s3c64xx/include/mach/map.h
index 23a1d71..8e2097b 100644
--- a/arch/arm/mach-s3c64xx/include/mach/map.h
+++ b/arch/arm/mach-s3c64xx/include/mach/map.h
@@ -115,6 +115,8 @@
#define S3C_PA_USB_HSOTG S3C64XX_PA_USB_HSOTG
#define S3C_PA_RTC S3C64XX_PA_RTC
#define S3C_PA_WDT S3C64XX_PA_WATCHDOG
+#define S3C_PA_SPI0S3C64XX_PA_SPI0
+#define S3C_PA_SPI1S3C64XX_PA_SPI1
#define SAMSUNG_PA_ADC S3C64XX_PA_ADC
#define SAMSUNG_PA_CFCON S3C64XX_PA_CFCON
diff --git a/arch/arm/mach-s3c64xx/setup-spi.c
b/arch/arm/mach-s3c64xx/setup-spi.c
new file mode 100644
index 000..c802375
--- /dev/null
+++ b/arch/arm/mach-s3c64xx/setup-spi.c
@@ -0,0 +1,47 @@
+/* linux/arch/arm/mach-s3c64xx/setup-spi.c
+ *
+ * Copyright (C) 2011 Samsung Electronics Ltd.
+ * http://www.samsung.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include
+#include
+
+#ifdef CONFIG_S3C64XX_DEV_SPI0
+struct s3c64xx_spi_info s3c64xx_spi0_pdata __initdata = {
+ .fifo_lvl_mask = 0x7f,
+ .rx_lvl_offset = 13,
+ .tx_st_done = 21,
+ .cntrlr_no = 0,
+};
+
+int s3c64xx_spi0_cfg_gpio(struct platform_device *dev)
+{
+ s3c_gpio_cfgall_range(S3C64XX_GPC(0), 3,
+ S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_S3C64XX_DEV_SPI1
+struct s3c64xx_spi_info s3c64xx_spi1_pdata __initdata = {
+ .fifo_lvl_mask = 0x7f,
+ .rx_lvl_offset = 13,
+ .tx_st_done = 21,
+ .cntrlr_no = 1,
+};
+
+int s3c64xx_spi1_cfg_gpio(struct platform_device *dev)
+{
+ s3c_gpio_cfgall_range(S3C64XX_GPC(4), 3,
+ S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
+ return 0;
+}
+#endif
diff --git a/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
b/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
index 483dfba..ff19e6c 100644
--- a/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
+++ b/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
@@ -69,4 +69,11 @@ struct s3c64xx_spi_info {
*/
extern void s3c64xx_spi_set_platdata(struct s3c64xx_spi_info *pd,
int src_clk_nr, int num_cs);
+
+/* defined by architecture to configure gpio */
+extern int s3c64xx_spi0_cfg_gpio(struct platform_device *dev);
+extern int s3c64xx_spi1_cfg_gpio(struct platform_device *dev);
+
+extern struct s3c64xx_spi_info s3c64xx_spi0_pdata;
+extern struct s3c64xx_spi_info s3c64xx_spi1_pdata;
#endif /* __S3C64XX_PLAT_SPI_H */
--
1.7.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
[PATCH V2 3/6] ARM: S5PC100: Modified files for SPI consolidation work.
As SPI platform devices are consolidated to plat-samsung, some
corresponding changes are required in the respective machine folder.
Setup files are added for SPI GPIO configurations and platform data
initialization.
Signed-off-by: Padmavathi Venna
---
arch/arm/mach-s5pc100/Kconfig|5 ++
arch/arm/mach-s5pc100/Makefile |1 +
arch/arm/mach-s5pc100/include/mach/map.h |3 +
arch/arm/mach-s5pc100/setup-spi.c| 68 ++
arch/arm/plat-samsung/include/plat/s3c64xx-spi.h |2 +
5 files changed, 79 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s5pc100/setup-spi.c
diff --git a/arch/arm/mach-s5pc100/Kconfig b/arch/arm/mach-s5pc100/Kconfig
index e538a4c..75a26ea 100644
--- a/arch/arm/mach-s5pc100/Kconfig
+++ b/arch/arm/mach-s5pc100/Kconfig
@@ -45,6 +45,11 @@ config S5PC100_SETUP_SDHCI_GPIO
help
Common setup code for SDHCI gpio.
+config S5PC100_SETUP_SPI
+ bool
+ help
+ Common setup code for SPI GPIO configurations.
+
config MACH_SMDKC100
bool "SMDKC100"
select CPU_S5PC100
diff --git a/arch/arm/mach-s5pc100/Makefile b/arch/arm/mach-s5pc100/Makefile
index 238a836..291e246 100644
--- a/arch/arm/mach-s5pc100/Makefile
+++ b/arch/arm/mach-s5pc100/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_S5PC100_SETUP_I2C1) += setup-i2c1.o
obj-$(CONFIG_S5PC100_SETUP_IDE)+= setup-ide.o
obj-$(CONFIG_S5PC100_SETUP_KEYPAD) += setup-keypad.o
obj-$(CONFIG_S5PC100_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
+obj-$(CONFIG_S5PC100_SETUP_SPI)+= setup-spi.o
# device support
obj-y += dev-audio.o
diff --git a/arch/arm/mach-s5pc100/include/mach/map.h
b/arch/arm/mach-s5pc100/include/mach/map.h
index ccbe6b7..54bc4f8 100644
--- a/arch/arm/mach-s5pc100/include/mach/map.h
+++ b/arch/arm/mach-s5pc100/include/mach/map.h
@@ -100,6 +100,9 @@
#define S3C_PA_USB_HSOTG S5PC100_PA_USB_HSOTG
#define S3C_PA_USB_HSPHY S5PC100_PA_USB_HSPHY
#define S3C_PA_WDT S5PC100_PA_WATCHDOG
+#define S3C_PA_SPI0S5PC100_PA_SPI0
+#define S3C_PA_SPI1S5PC100_PA_SPI1
+#define S3C_PA_SPI2S5PC100_PA_SPI2
#define S5P_PA_CHIPID S5PC100_PA_CHIPID
#define S5P_PA_FIMC0 S5PC100_PA_FIMC0
diff --git a/arch/arm/mach-s5pc100/setup-spi.c
b/arch/arm/mach-s5pc100/setup-spi.c
new file mode 100644
index 000..845a732
--- /dev/null
+++ b/arch/arm/mach-s5pc100/setup-spi.c
@@ -0,0 +1,68 @@
+/* linux/arch/arm/mach-s5pc100/setup-spi0.c
+ *
+ * Copyright (C) 2011 Samsung Electronics Ltd.
+ * http://www.samsung.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include
+#include
+
+#ifdef CONFIG_S3C64XX_DEV_SPI0
+struct s3c64xx_spi_info s3c64xx_spi0_pdata __initdata = {
+ .fifo_lvl_mask = 0x7f,
+ .rx_lvl_offset = 13,
+ .high_speed = 1,
+ .tx_st_done = 21,
+ .cntrlr_no = 0,
+};
+
+int s3c64xx_spi0_cfg_gpio(struct platform_device *dev)
+{
+ s3c_gpio_cfgall_range(S5PC100_GPB(0), 3,
+ S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_S3C64XX_DEV_SPI1
+struct s3c64xx_spi_info s3c64xx_spi1_pdata __initdata = {
+ .fifo_lvl_mask = 0x7f,
+ .rx_lvl_offset = 13,
+ .high_speed = 1,
+ .tx_st_done = 21,
+ .cntrlr_no = 1,
+};
+
+int s3c64xx_spi1_cfg_gpio(struct platform_device *dev)
+{
+ s3c_gpio_cfgall_range(S5PC100_GPB(4), 3,
+ S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_S3C64XX_DEV_SPI2
+struct s3c64xx_spi_info s3c64xx_spi2_pdata __initdata = {
+ .fifo_lvl_mask = 0x7f,
+ .rx_lvl_offset = 13,
+ .high_speed = 1,
+ .tx_st_done = 21,
+ .cntrlr_no = 2,
+};
+
+int s3c64xx_spi2_cfg_gpio(struct platform_device *dev)
+{
+ s3c_gpio_cfgpin(S5PC100_GPG3(0), S3C_GPIO_SFN(3));
+ s3c_gpio_setpull(S5PC100_GPG3(0), S3C_GPIO_PULL_UP);
+ s3c_gpio_cfgall_range(S5PC100_GPB(2), 2,
+ S3C_GPIO_SFN(3), S3C_GPIO_PULL_UP);
+ return 0;
+}
+#endif
diff --git a/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
b/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
index ff19e6c..ba76eea 100644
--- a/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
+++ b/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
@@ -73,7 +73,9 @@ extern void s3c64xx_spi_set_platdata(struct s3c64xx_spi_info
*pd,
/* defined by architecture to configure gpio */
extern int s3c64xx_spi0_cfg_gpio(struct platform_device *dev);
extern int s3c64xx_spi1_cfg_gpio(struct platform_device *dev);
+ex
[PATCH V2 4/6] ARM: S5P64X0: Modified files for SPI consolidation work
As SPI platform devices are consolidated to plat-samsung, some
corresponding changes are required in the respective machine folder.
Setup files are added for SPI GPIO configurations and platform data
initialization.
Signed-off-by: Padmavathi Venna
---
arch/arm/mach-s5p64x0/Kconfig|7 +++-
arch/arm/mach-s5p64x0/Makefile |1 +
arch/arm/mach-s5p64x0/include/mach/map.h |3 ++
arch/arm/mach-s5p64x0/setup-spi.c| 57 ++
4 files changed, 66 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-s5p64x0/setup-spi.c
diff --git a/arch/arm/mach-s5p64x0/Kconfig b/arch/arm/mach-s5p64x0/Kconfig
index 18690c5..dd8c85e 100644
--- a/arch/arm/mach-s5p64x0/Kconfig
+++ b/arch/arm/mach-s5p64x0/Kconfig
@@ -36,6 +36,11 @@ config S5P64X0_SETUP_I2C1
help
Common setup code for i2c bus 1.
+config S5P64X0_SETUP_SPI
+ bool
+ help
+ Common setup code for SPI GPIO configurations
+
# machine support
config MACH_SMDK6440
@@ -45,7 +50,6 @@ config MACH_SMDK6440
select S3C_DEV_I2C1
select S3C_DEV_RTC
select S3C_DEV_WDT
- select S3C64XX_DEV_SPI
select SAMSUNG_DEV_ADC
select SAMSUNG_DEV_BACKLIGHT
select SAMSUNG_DEV_PWM
@@ -62,7 +66,6 @@ config MACH_SMDK6450
select S3C_DEV_I2C1
select S3C_DEV_RTC
select S3C_DEV_WDT
- select S3C64XX_DEV_SPI
select SAMSUNG_DEV_ADC
select SAMSUNG_DEV_BACKLIGHT
select SAMSUNG_DEV_PWM
diff --git a/arch/arm/mach-s5p64x0/Makefile b/arch/arm/mach-s5p64x0/Makefile
index e24d316..a7d7a49 100644
--- a/arch/arm/mach-s5p64x0/Makefile
+++ b/arch/arm/mach-s5p64x0/Makefile
@@ -29,3 +29,4 @@ obj-y += dev-audio.o
obj-$(CONFIG_S5P64X0_SETUP_I2C1) += setup-i2c1.o
obj-$(CONFIG_S5P64X0_SETUP_FB_24BPP) += setup-fb-24bpp.o
+obj-$(CONFIG_S5P64X0_SETUP_SPI)+= setup-spi.o
diff --git a/arch/arm/mach-s5p64x0/include/mach/map.h
b/arch/arm/mach-s5p64x0/include/mach/map.h
index 4d3ac8a..c6af0fc 100644
--- a/arch/arm/mach-s5p64x0/include/mach/map.h
+++ b/arch/arm/mach-s5p64x0/include/mach/map.h
@@ -67,6 +67,8 @@
#define S3C_PA_RTC S5P64X0_PA_RTC
#define S3C_PA_WDT S5P64X0_PA_WDT
#define S3C_PA_FB S5P64X0_PA_FB
+#define S3C_PA_SPI0S5P64X0_PA_SPI0
+#define S3C_PA_SPI1S5P64X0_PA_SPI1
#define S5P_PA_CHIPID S5P64X0_PA_CHIPID
#define S5P_PA_SROMC S5P64X0_PA_SROMC
@@ -75,6 +77,7 @@
#define SAMSUNG_PA_ADC S5P64X0_PA_ADC
+
/* UART */
#define S5P6440_PA_UART(x) (0xEC00 + ((x) * S3C_UART_OFFSET))
diff --git a/arch/arm/mach-s5p64x0/setup-spi.c
b/arch/arm/mach-s5p64x0/setup-spi.c
new file mode 100644
index 000..fb66ff9
--- /dev/null
+++ b/arch/arm/mach-s5p64x0/setup-spi.c
@@ -0,0 +1,57 @@
+/* linux/arch/arm/mach-s5p64x0/setup-spi0.c
+ *
+ * Copyright (C) 2011 Samsung Electronics Ltd.
+ * http://www.samsung.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#ifdef CONFIG_S3C64XX_DEV_SPI0
+struct s3c64xx_spi_info s3c64xx_spi0_pdata __initdata = {
+ .fifo_lvl_mask = 0x1ff,
+ .rx_lvl_offset = 15,
+ .tx_st_done = 25,
+ .cntrlr_no = 0,
+};
+
+int s3c64xx_spi0_cfg_gpio(struct platform_device *dev)
+{
+ if (soc_is_s5p6450())
+ s3c_gpio_cfgall_range(S5P6450_GPC(0), 3,
+ S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
+ else
+ s3c_gpio_cfgall_range(S5P6440_GPC(0), 3,
+ S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_S3C64XX_DEV_SPI1
+struct s3c64xx_spi_info s3c64xx_spi1_pdata __initdata = {
+ .fifo_lvl_mask = 0x7f,
+ .rx_lvl_offset = 15,
+ .tx_st_done = 25,
+ .cntrlr_no = 1,
+};
+
+int s3c64xx_spi1_cfg_gpio(struct platform_device *dev)
+{
+ if (soc_is_s5p6450())
+ s3c_gpio_cfgall_range(S5P6450_GPC(4), 3,
+ S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
+ else
+ s3c_gpio_cfgall_range(S5P6440_GPC(4), 3,
+ S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
+ return 0;
+}
+#endif
--
1.7.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
[PATCH V2 5/6] ARM: S5PV210: Modified files for SPI consolidation work
As SPI platform devices are consolidated to plat-samsung, some
corresponding changes are required in the respective machine folder.
Setup files are added for SPI GPIO configurations and platform data
initialization.
Signed-off-by: Padmavathi Venna
---
arch/arm/mach-s5pv210/Kconfig|5 +++
arch/arm/mach-s5pv210/Makefile |1 +
arch/arm/mach-s5pv210/include/mach/map.h |2 +
arch/arm/mach-s5pv210/setup-spi.c| 53 ++
4 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s5pv210/setup-spi.c
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 646057a..2cdc42e 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -60,6 +60,11 @@ config S5PV210_SETUP_FIMC
help
Common setup code for the camera interfaces.
+config S5PV210_SETUP_SPI
+ bool
+ help
+ Common setup code for SPI GPIO configurations.
+
menu "S5PC110 Machines"
config MACH_AQUILA
diff --git a/arch/arm/mach-s5pv210/Makefile b/arch/arm/mach-s5pv210/Makefile
index 7eb8677..471df5d 100644
--- a/arch/arm/mach-s5pv210/Makefile
+++ b/arch/arm/mach-s5pv210/Makefile
@@ -35,3 +35,4 @@ obj-$(CONFIG_S5PV210_SETUP_I2C2) += setup-i2c2.o
obj-$(CONFIG_S5PV210_SETUP_IDE)+= setup-ide.o
obj-$(CONFIG_S5PV210_SETUP_KEYPAD) += setup-keypad.o
obj-$(CONFIG_S5PV210_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
+obj-$(CONFIG_S5PV210_SETUP_SPI)+= setup-spi.o
diff --git a/arch/arm/mach-s5pv210/include/mach/map.h
b/arch/arm/mach-s5pv210/include/mach/map.h
index 7ff609f..89c34b8 100644
--- a/arch/arm/mach-s5pv210/include/mach/map.h
+++ b/arch/arm/mach-s5pv210/include/mach/map.h
@@ -109,6 +109,8 @@
#define S3C_PA_RTC S5PV210_PA_RTC
#define S3C_PA_USB_HSOTG S5PV210_PA_HSOTG
#define S3C_PA_WDT S5PV210_PA_WATCHDOG
+#define S3C_PA_SPI0S5PV210_PA_SPI0
+#define S3C_PA_SPI1S5PV210_PA_SPI1
#define S5P_PA_CHIPID S5PV210_PA_CHIPID
#define S5P_PA_FIMC0 S5PV210_PA_FIMC0
diff --git a/arch/arm/mach-s5pv210/setup-spi.c
b/arch/arm/mach-s5pv210/setup-spi.c
new file mode 100644
index 000..a1cdb9d
--- /dev/null
+++ b/arch/arm/mach-s5pv210/setup-spi.c
@@ -0,0 +1,53 @@
+/* linux/arch/arm/mach-s5pv210/setup-spi0.c
+ *
+ * Copyright (C) 2011 Samsung Electronics Ltd.
+ * http://www.samsung.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include
+#include
+
+#ifdef CONFIG_S3C64XX_DEV_SPI0
+struct s3c64xx_spi_info s3c64xx_spi0_pdata = {
+ .fifo_lvl_mask = 0x1ff,
+ .rx_lvl_offset = 15,
+ .high_speed = 1,
+ .tx_st_done = 25,
+ .cntrlr_no = 0,
+};
+
+int s3c64xx_spi0_cfg_gpio(struct platform_device *dev)
+{
+ s3c_gpio_cfgpin(S5PV210_GPB(0), S3C_GPIO_SFN(2));
+ s3c_gpio_setpull(S5PV210_GPB(0), S3C_GPIO_PULL_UP);
+ s3c_gpio_cfgall_range(S5PV210_GPB(2), 2,
+ S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_S3C64XX_DEV_SPI1
+struct s3c64xx_spi_info s3c64xx_spi1_pdata = {
+ .fifo_lvl_mask = 0x7f,
+ .rx_lvl_offset = 15,
+ .high_speed = 1,
+ .tx_st_done = 25,
+ .cntrlr_no = 1,
+};
+
+int s3c64xx_spi1_cfg_gpio(struct platform_device *dev)
+{
+ s3c_gpio_cfgpin(S5PV210_GPB(4), S3C_GPIO_SFN(2));
+ s3c_gpio_setpull(S5PV210_GPB(4), S3C_GPIO_PULL_UP);
+ s3c_gpio_cfgall_range(S5PV210_GPB(6), 2,
+ S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
+ return 0;
+}
+#endif
--
1.7.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
[PATCH V2 6/6] ARM: S3C64XX: Modified according to SPI consolidation work.
As SPI platform devices are consolidated to plat-samsung, some corresponding changes are required in the s3c6410 varient SoCs. Signed-off-by: Padmavathi Venna --- arch/arm/mach-s3c64xx/Kconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig index dea62bf..e9dae91 100644 --- a/arch/arm/mach-s3c64xx/Kconfig +++ b/arch/arm/mach-s3c64xx/Kconfig @@ -281,6 +281,7 @@ config MACH_WLF_CRAGG_6410 select S3C64XX_SETUP_IDE select S3C64XX_SETUP_FB_24BPP select S3C64XX_SETUP_KEYPAD + select S3C64XX_SETUP_SPI select SAMSUNG_DEV_ADC select SAMSUNG_DEV_KEYPAD select S3C_DEV_USB_HOST @@ -291,7 +292,7 @@ config MACH_WLF_CRAGG_6410 select S3C_DEV_I2C1 select S3C_DEV_WDT select S3C_DEV_RTC - select S3C64XX_DEV_SPI + select S3C64XX_DEV_SPI0 select SAMSUNG_GPIO_EXTRA128 select I2C help -- 1.7.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
[PATCH V2] ARM: EXYNOS4: Add SPI support
Add SPI setup files for GPIO configurations and platform data
initialization.
Add SPI clkdev support.
Signed-off-by: Padmavathi Venna
---
arch/arm/mach-exynos/Kconfig |5 ++
arch/arm/mach-exynos/Makefile |1 +
arch/arm/mach-exynos/clock.c | 73 ++--
arch/arm/mach-exynos/include/mach/irqs.h |3 +
arch/arm/mach-exynos/include/mach/map.h|7 ++
arch/arm/mach-exynos/include/mach/spi-clocks.h | 17 +
arch/arm/mach-exynos/setup-spi.c | 75
7 files changed, 151 insertions(+), 30 deletions(-)
create mode 100644 arch/arm/mach-exynos/include/mach/spi-clocks.h
create mode 100644 arch/arm/mach-exynos/setup-spi.c
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 0afcc3b..c925fec 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -148,6 +148,11 @@ config EXYNOS4_SETUP_USB_PHY
help
Common setup code for USB PHY controller
+config EXYNOS4_SETUP_SPI
+ bool
+ help
+ Common setup code for SPI GPIO configurations.
+
# machine support
if ARCH_EXYNOS4
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 57e5296..979fdd3 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -60,3 +60,4 @@ obj-$(CONFIG_EXYNOS4_SETUP_I2C7) += setup-i2c7.o
obj-$(CONFIG_EXYNOS4_SETUP_KEYPAD) += setup-keypad.o
obj-$(CONFIG_EXYNOS4_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
obj-$(CONFIG_EXYNOS4_SETUP_USB_PHY)+= setup-usb-phy.o
+obj-$(CONFIG_EXYNOS4_SETUP_SPI)+= setup-spi.o
diff --git a/arch/arm/mach-exynos/clock.c b/arch/arm/mach-exynos/clock.c
index 5d8d483..da50b1a 100644
--- a/arch/arm/mach-exynos/clock.c
+++ b/arch/arm/mach-exynos/clock.c
@@ -,36 +,6 @@ static struct clksrc_clk clksrcs[] = {
.reg_div = { .reg = S5P_CLKDIV_LCD0, .shift = 0, .size = 4 },
}, {
.clk= {
- .name = "sclk_spi",
- .devname= "s3c64xx-spi.0",
- .enable = exynos4_clksrc_mask_peril1_ctrl,
- .ctrlbit= (1 << 16),
- },
- .sources = &clkset_group,
- .reg_src = { .reg = S5P_CLKSRC_PERIL1, .shift = 16, .size = 4 },
- .reg_div = { .reg = S5P_CLKDIV_PERIL1, .shift = 0, .size = 4 },
- }, {
- .clk= {
- .name = "sclk_spi",
- .devname= "s3c64xx-spi.1",
- .enable = exynos4_clksrc_mask_peril1_ctrl,
- .ctrlbit= (1 << 20),
- },
- .sources = &clkset_group,
- .reg_src = { .reg = S5P_CLKSRC_PERIL1, .shift = 20, .size = 4 },
- .reg_div = { .reg = S5P_CLKDIV_PERIL1, .shift = 16, .size = 4 },
- }, {
- .clk= {
- .name = "sclk_spi",
- .devname= "s3c64xx-spi.2",
- .enable = exynos4_clksrc_mask_peril1_ctrl,
- .ctrlbit= (1 << 24),
- },
- .sources = &clkset_group,
- .reg_src = { .reg = S5P_CLKSRC_PERIL1, .shift = 24, .size = 4 },
- .reg_div = { .reg = S5P_CLKDIV_PERIL2, .shift = 0, .size = 4 },
- }, {
- .clk= {
.name = "sclk_fimg2d",
},
.sources = &clkset_mout_g2d,
@@ -1257,6 +1227,42 @@ static struct clksrc_clk clk_sclk_mmc3 = {
.reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 24, .size = 8 },
};
+static struct clksrc_clk clk_sclk_spi0 = {
+ .clk= {
+ .name = "sclk_spi",
+ .devname= "s3c64xx-spi.0",
+ .enable = exynos4_clksrc_mask_peril1_ctrl,
+ .ctrlbit= (1 << 16),
+ },
+ .sources = &clkset_group,
+ .reg_src = { .reg = S5P_CLKSRC_PERIL1, .shift = 16, .size = 4 },
+ .reg_div = { .reg = S5P_CLKDIV_PERIL1, .shift = 0, .size = 4 },
+};
+
+static struct clksrc_clk clk_sclk_spi1 = {
+ .clk= {
+ .name = "sclk_spi",
+ .devname= "s3c64xx-spi.1",
+ .enable = exynos4_clksrc_mask_peril1_ctrl,
+ .ctrlbit= (1 << 20),
+ },
+ .sources = &clkset_group,
+ .reg_src = { .reg = S5P_CLKSRC_PERIL1, .shift = 20, .size = 4 },
+ .reg_div = { .reg = S5P_CLKDIV_PERIL1, .shift = 16, .size = 4 },
+};
+
+static struct clksrc_clk clk_sclk_spi2 = {
+ .clk= {
+ .name = "sclk_spi",
+ .devname
