On Tue, Sep 25, 2012 at 04:00:18AM -0400, Chris Ball wrote:
> Hi,
>
> On Tue, Sep 25 2012, Shawn Guo wrote:
> > On Tue, Sep 25, 2012 at 03:52:09AM -0400, Chris Ball wrote:
> >> We could also break the stalemate by just changing the common spec to
> >> have bus-width become optional, default 4. It
On Tue, Sep 25, 2012 at 04:50:52PM +0800, Shawn Guo wrote:
> On Tue, Sep 25, 2012 at 10:05:25AM +0200, Sascha Hauer wrote:
> > Ok, how about this:
> >
> > - I add a bus-width = <4> property to all i.MX dtsi files
> > - we merge the patch adding bus-width as an optional property
> > - Make the bus-
On Tue, Sep 25, 2012 at 10:05:25AM +0200, Sascha Hauer wrote:
> Ok, how about this:
>
> - I add a bus-width = <4> property to all i.MX dtsi files
> - we merge the patch adding bus-width as an optional property
> - Make the bus-width option mandatory in the next step.
>
> This way we can merge the
On Tue, Sep 25, 2012 at 03:45:50PM +0800, Shawn Guo wrote:
> On Tue, Sep 25, 2012 at 09:38:08AM +0200, Sascha Hauer wrote:
> > So you want to make the code conform to the common spec which has
> > bus-width as a required property. Is this really worth it to add an
> > incompatible change to our dev
Hi,
On Tue, Sep 25 2012, Shawn Guo wrote:
> On Tue, Sep 25, 2012 at 03:52:09AM -0400, Chris Ball wrote:
>> We could also break the stalemate by just changing the common spec to
>> have bus-width become optional, default 4. It's not going to break the
>> code of anyone who's been treating it as re
On Tue, Sep 25, 2012 at 09:38:08AM +0200, Sascha Hauer wrote:
> So you want to make the code conform to the common spec which has
> bus-width as a required property. Is this really worth it to add an
> incompatible change to our devicetrees?
>
I do want to have our implementation conform to common
On Tue, Sep 25, 2012 at 03:52:09AM -0400, Chris Ball wrote:
> We could also break the stalemate by just changing the common spec to
> have bus-width become optional, default 4. It's not going to break the
> code of anyone who's been treating it as required. I don't think there
> there was a princ
Hi,
On Tue, Sep 25 2012, Sascha Hauer wrote:
>> > > > +- bus-width : Maximum supported bus width. Defaults to 4 if omitted
>> > > >
>> > > This is a common mmc property documented in bindings/mmc/mmc.txt.
>> > > Instead of duplicating the documentation, we should try to make our
>> > > implementat
On Tue, Sep 25, 2012 at 03:33:19PM +0800, Shawn Guo wrote:
> On Tue, Sep 25, 2012 at 09:27:15AM +0200, Sascha Hauer wrote:
> > > > Optional properties:
> > > > - fsl,cd-controller : Indicate to use controller internal card
> > > > detection
> > > > - fsl,wp-controller : Indicate to use controll
On Tue, Sep 25, 2012 at 09:27:15AM +0200, Sascha Hauer wrote:
> > > Optional properties:
> > > - fsl,cd-controller : Indicate to use controller internal card detection
> > > - fsl,wp-controller : Indicate to use controller internal write
> > > protection
> > > +- bus-width : Maximum supported b
On Tue, Sep 25, 2012 at 03:15:08PM +0800, Shawn Guo wrote:
> On Mon, Sep 24, 2012 at 09:22:25AM +0200, Sascha Hauer wrote:
> > The i.MX esdhc has a nonstandard bit layout for the SDHCI_HOST_CONTROL
> > register. To support 8bit bus width on i.MX populate the platform_bus_width
> > callback. This is
On Mon, Sep 24, 2012 at 09:22:25AM +0200, Sascha Hauer wrote:
> The i.MX esdhc has a nonstandard bit layout for the SDHCI_HOST_CONTROL
> register. To support 8bit bus width on i.MX populate the platform_bus_width
> callback. This is tested on an i.MX25, but should according to the datasheets
> work
The i.MX esdhc has a nonstandard bit layout for the SDHCI_HOST_CONTROL
register. To support 8bit bus width on i.MX populate the platform_bus_width
callback. This is tested on an i.MX25, but should according to the datasheets
work on the other i.MX using this hardware aswell. The i.MX6, while having
13 matches
Mail list logo
