Re: [PATCH] mmc: omap_hsmmc: use for OMAP5 as well

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 08, 2013 at 05:27:50PM -0300, Ezequiel Garcia wrote:
> On Mon, Jul 08, 2013 at 02:58:28PM -0500, Nishanth Menon wrote:
> > On 10:46-20130708, Felipe Balbi wrote:
> > > On Sun, Jul 07, 2013 at 05:13:10PM -0300, Ezequiel Garcia wrote:
> > > > Hi guys,
> > > > 
> > > > On Fri, Jun 28, 2013 at 09:27:20PM +0530, Balaji T K wrote:
> > > > > On Friday 28 June 2013 06:04 PM, a-bindra@xxxxxx wrote:
> > > > > > From: Amarinder Bindra <a-bindra@xxxxxx>
> > > > > >
> > > > > > OMAP's hs_mmc driver is also used for OMAP5 MMC controller operation.
> > > > > > Considering that the device tree entries are already there for this,
> > > > > > allow the driver to be built when only OMAP5 is enabled.
> > > > > > This allows MMC root filesystems to be available in "OMAP5 only"
> > > > > > configurations.
> > > > > >
> > > > > > Signed-off-by: Amarinder Bindra <a-bindra@xxxxxx>
> > > > > > Acked-by: Felipe Balbi <balbi@xxxxxx>
> > > > > > Acked-by: Nishanth Menon <nm@xxxxxx>
> > > > > 
> > > > > Looks good to me,
> > > > > Acked-by: Balaji T K <balajitk@xxxxxx>
> > > > > 
> > > > 
> > > > I came across this same issue while trying MMC patches on AM3xx,
> > > > which is nor OMAP3 neither OMAP4.
> > > > 
> > > > Now, looking at the driver I don't see any OMAP-specific bits
> > > > (welcome to the multiplatform world ;-) so I think we can just
> > > > remove the 'depends' line. Something like this:
> > > 
> > > frankly speaking, this driver should be deleted and all users should be
> > > moved to sdhci. OMAP's HSMMC controller is compatible with SDHCI except
> > > for a couple quirks which can be easily worked around.
> 
> @Felipe:
> Do you mind giving me some hints about this quirks? I'm not too familiar
> with these drivers.

one of the quirks is that TI decided to registers into one (because they
both had 16-bits reserved, so, well, we can make the HW 0.0000000000001
dollar cheaper :-p )

The other is related where our SDHCI registers start. Because of TI's
added registers (SYSConfig and REVISION, etc), SDHCI registers have an
offset which generic SDHCI driver, doesn't cope with right now.

> > Do we take that as a NAK to this specific patch?
> > 
> > I am not complaining about the future migration to a solution that is
> > much more generic and scalable, but having fixes for current problems
> > should'nt be ignored IMHO.
> > 
> 
> Of course.
> 
> > How about a depends on CONFIG_ARCH_OMAP2PLUS instead? will that solve
> > our pains with all OMAP2+ usin this?
> 
> Yes, I think that using ARCH_OMAP2PLUS should do. FWIW, until we have
> sdhci ready to replace omap_hsmmc, we have no choice but to apply such
> a patch.

if you do change to ARCH_OMAP2PLUS, please also add COMPILE_TEST
(ARCH_OMAP2PLUS || COMPILE_TEST) so we can build in other archs.

-- 
balbi

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux