[lkml]   [2009]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: MMC: Make the configuration memory resource optional
    Hi Ian,

    On Tue, Jul 28, 2009 at 10:55 PM, Ian Molton<> wrote:
    > Guennadi Liakhovetski wrote:
    >> Add support for tmio_mmc hardware configurations, that lack the cnf io
    >> area, like SuperH SoCs. With this patch such hardware can pass a single ctl
    >> io area with the platform data.
    > NAK

    That's not a very polite way to begin your email. How about "hey, hi
    or good day"?

    > I dont like this approach - although it involves minimal changes to the
    > driver, it will leave people puzzling over why their accesses to the cnf
    > registers do nothing when debugging.

    Half a year ago I posted a set of tmio_mmc patches, and the MMC
    maintainer kindly picked out the bug fixes and merged them. No problem
    there. The feature request to allow the driver to work with a single
    memory window (similar to this patch) was NAKed by you in a very
    similar way.

    One of the reasons for NAKing my patches at that time was that you
    didn't have time to review the 100 lines of code. This time you
    dislike it because "it will leave people puzzling".

    > The cnf area is basically clock and power control for devices that have it.
    > If I had known of the existence of other tmio devices that didnt do it that
    > way when I wrote the driver, it would never have been put in there directly.
    > The *right* way to do this is to use the clk API for clocks and provide a
    > small API for power control that the driver will use, if present.

    Yes, I think everyone wants to use the clock API to control clocks.

    However, the clock API does not solve the issue with a single address
    window. That's the issue that this patch and my earlier patches are
    trying to solve. Which is the issue that you keep on ignoring.

    > If people want to change the situation in TMIO re: clocks, as I have said
    > before, they should start a discussion on how to adapt the clk API.  so that
    > more than just the CPU can use it. This will make everyone happy all in one
    > go.

    Regardless of how the clock API is implemented, sooner or later the
    driver needs to support a single address window if it's going to run
    on such hardware. This is not exactly rocket science.

    > I will happily take a patch abstracting power control from tmio-mmc,
    > however.

    I see it as you are blocking progress without any technical reasons.
    It's basically exactly the same as half a year ago. And exactly what
    has happened with clocklib in that time?

    I understand that you want to have clocklib so you can manage clocks
    dynamically for your mfd drivers, but in our use case we already have
    working clock framework implementations withing our SoC. There is no
    need for any dynamic clock registration and unregistration. With that
    in mind it can't be very difficult to understand that there is no
    point for SoC vendors to work on clocklib. If's mainly an issue for

    You talk about correctness in the upstream kernel and refuse to
    include things because of your special view of correctness. At the
    same time you suggest Guennadi and me to keep the patches local
    instead of picking up the changes and merging them in your upstream
    driver. This local patch suggestion does not help. If we wanted to
    have local patches then we wouldn't submit things upstream.

    Your role as a maintainer is to work with the community. Just NAKing
    and saying you want some highlevel framework merged first is not very
    constructive. I recommend you to evaluate your position in the
    communtiy. Use git shortlog to compare your own contributions over
    time with what Guennadi has done.

    / magnus
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-07-29 04:51    [W:0.027 / U:2.608 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site