Re: RFC: A better clock rounding API?
Btw, if we are going to pass a rate range from the driver, we might as well make it clk_set_rate_range(). By passing the range, we rule out the possibility of any catastrophic rates -- so clk_find_rate() seems less useful. Thanks, Sarav P.S: murphy++; Found a correction just after I sent the email but not on any of the several iterations of proof reading that preceded it. Saravana Kannan wrote: I'm mostly familiar with ARM. So I will limit the discussion to ARM boards/machines. But I think the points raised in this email would apply for most architectures. I'm sending this to the ARM mailing list first to see if I can get a consensus within the ARM community before I propose this to the wider audience in LKML. The meaning of clk_round_rate() is very ambiguous since the nature of the rounding is architecture and platform specific. In the case of ARM, it's up to each ARM mach's clock driver to determine how it wants to round the rate. To quote Russel King from an email about a month ago: "clk_round_rate() returns the clock rate which will be set if you ask clk_set_rate() to set that rate. It provides a way to query from the implementation exactly what rate you'll get if you use clk_set_rate() with that same argument." So when someone writes a device driver for a device that's external to the SoC or is integrated into more than one SoC, they currently have the following options to deal with clock rates differences: 1. Use clk_round_rate() to get clock rates and test their driver on the one/few board(s) they have at hand and hope it works on boards using different SoCs. 2. Add each and every needed clock rate (low power rate, high performance rate, handshake rate, etc) as fields to their platform data and have it populated in every board file that uses the device. 3. Do a search of the frequency space of the clock by making several clk_round_rate() calls at various intervals between their minimum and maximum acceptable rates and hope to find one of the supported rates. If clk_round_rate() does a +/- N percentage rounding and the interval is larger, even this searching might not find an existing rate that's supported between the driver's min and max acceptable rates. IMHO, each of these options have short comings that could be alleviated by adding a more definitive "rounding" API. Also, considering that it's the consumer of each clock that knows best what amount of rounding and in which direction is acceptable, IMHO the current approach of hiding the rounding inside the clock drivers seems counter intuitive. I would like to propose the addition of either: long clk_find_rate(struct clk *clk, unsigned long min_rate, long max_rate); or long clk_find_rate(struct clk *clk, unsigned long start_rate, long end_rate); The advantage of the 2nd suggestion is that it allows a driver to specify which end of a frequency range it prefers. But I'm not sure how important of an advantage that is. So, proposing both and having the community decide which one, if any, is acceptable. If the clk_find_rate() API is available, the driver developer wouldn't have to worry about figuring out a way for the clk_set_rate() to work on different platforms/machs/SoCs. If a platform/mach/SoC can provide a clock rate that's acceptable to their hardware and software requirements, then they can be assured to find it without having to jump through hoops or having a driver not work when it could have. Does the addition of one of the suggested APIs sound reasonable? If not, can someone explain what the right/better solution is? If the addition of a new API is reasonable, what's the community preference between the two suggestion? If I submit a patch that will add one of the APIs is it likely to be accepted? Thanks for your time. -Sarav -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: A better clock rounding API?
I'm mostly familiar with ARM. So I will limit the discussion to ARM boards/machines. But I think the points raised in this email would apply for most architectures. I'm sending this to the ARM mailing list first to see if I can get a consensus within the ARM community before I propose this to the wider audience in LKML. The meaning of clk_round_rate() is very ambiguous since the nature of the rounding is architecture and platform specific. In the case of ARM, it's up to each ARM mach's clock driver to determine how it wants to round the rate. To quote Russel King from an email about a month ago: "clk_round_rate() returns the clock rate which will be set if you ask clk_set_rate() to set that rate. It provides a way to query from the implementation exactly what rate you'll get if you use clk_set_rate() with that same argument." So when someone writes a device driver for a device that's external to the SoC or is integrated into more than one SoC, they currently have the following options to deal with clock rates differences: 1. Use clk_round_rate() to get clock rates and test their driver on the one/few board(s) they have at hand and hope it works on boards using different SoCs. 2. Add each and every needed clock rate (low power rate, high performance rate, handshake rate, etc) as fields to their platform data and have it populated in every board file that uses the device. 3. Do a search of the frequency space of the clock by making several clk_round_rate() calls at various intervals between their minimum and maximum acceptable rates and hope to find one of the supported rates. If clk_round_rate() does a +/- N percentage rounding and the interval is larger, even this searching might not find an existing rate that's supported between the driver's min and max acceptable rates. IMHO, each of these options have short comings that could be alleviated by adding a more definitive "rounding" API. Also, considering that it's the consumer of each clock that knows best what amount of rounding and in which direction is acceptable, IMHO the current approach of hiding the rounding inside the clock drivers seems counter intuitive. I would like to propose the addition of either: long clk_find_rate(struct clk *clk, unsigned long min_rate, long max_rate); or long clk_find_rate(struct clk *clk, unsigned long start_rate, long end_rate); The advantage of the 2nd suggestion is that it allows a driver to specify which end of a frequency range it prefers. But I'm not sure how important of an advantage that is. So, proposing both and having the community decide which one, if any, is acceptable. If the clk_find_rate() API is available, the driver developer wouldn't have to worry about figuring out a way for the clk_set_rate() to work on different platforms/machs/SoCs. If a platform/mach/SoC can provide a clock rate that's acceptable to their hardware and software requirements, then they can be assured to find it without having to jump through hoops or having a driver not work when it could have. Does the addition of one of the suggested APIs sound reasonable? If not, can someone explain what the right/better solution is? If the addition of a new API is reasonable, what's the community preference between the two suggestion? If I submit a patch that will add one of the APIs is it likely to be accepted? Thanks for your time. -Sarav -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Bluetooth: Add socket option definitions for AMP
This adds a new BT_AMP socket option to control the use of AMP channels.
It is for use with the SOL_BLUETOOTH option level on L2CAP sockets.
Available option values are defined as:
BT_AMP_REQUIRE_BR_EDR
* Default
* AMP controllers cannot be used
* Channel move requests from the remote device are denied
* If the L2CAP channel is currently using AMP, move the channel to
BR/EDR
BT_AMP_PREFER_AMP
* Allow use of AMP controllers
* If the L2CAP channel is currently on BR/EDR and AMP controller
resources are available, initiate a channel move to AMP
* Channel move requests from the remote device are allowed
* If the L2CAP socket has not been connected yet, try to create
and configure the channel directly on an AMP controller rather
than BR/EDR
BT_AMP_PREFER_BR_EDR
* Allow use of AMP controllers
* If the L2CAP channel is currently on AMP, move it to BR/EDR
* Channel move requests from the remote device are allowed
Signed-off-by: Mat Martineau
---
include/net/bluetooth/bluetooth.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/bluetooth.h
b/include/net/bluetooth/bluetooth.h
index 27a902d..0d41b99 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -64,6 +64,11 @@ struct bt_security {
#define BT_DEFER_SETUP 7
+#define BT_AMP 8
+#define BT_AMP_REQUIRE_BR_EDR 0
+#define BT_AMP_PREFER_AMP 1
+#define BT_AMP_PREFER_BR_EDR 2
+
#define BT_INFO(fmt, arg...) printk(KERN_INFO "Bluetooth: " fmt "\n" , ## arg)
#define BT_ERR(fmt, arg...) printk(KERN_ERR "%s: " fmt "\n" , __func__ , ##
arg)
#define BT_DBG(fmt, arg...) pr_debug("%s: " fmt "\n" , __func__ , ## arg)
--
1.7.1
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regulator voltage aggregation
On Tue, Aug 17, 2010 at 01:44:36PM -0700, Bobby Crabtree wrote: > Only remaining question I have is if the aggregation of > multiple consumer constraints should be the default (and only) > behavior. Or should we introduce a new flag to the > regulator_constraints structure that tells the core to aggregate > consumer voltages constraints? I'd say make it the only behaviour - if there is only one consumer it decays into the same behaviour as we have currently, and since voltage changes need to be explicitly enabled by the machine constraints it should not affect any existing machines. One thing to take account of is an attempt to set a constraint which can't be accomodated by the other enabled devices, or enable a device which has constraints outside the currently allowed range. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regulator voltage aggregation
Mark Brown wrote: > On Tue, Aug 17, 2010 at 12:33:33PM -0700, Bobby Crabtree wrote: >> Mark Brown wrote: > >>> It's unlikely that the highest voltage would ever be the best choice... > >> We do need the highest voltage. Let's say we have two consumers >> (A and B). Both require 1.3V for "normal" operations. Then let's >> say that consumer A can save power by reducing the voltage to 1.1V >> (but it doesn't require 1.1V). If the core were to immediately apply >> 1.1V, then the 1.3V requirement of consumer B would not be satisfied. > > That's not the highest voltage, that's the minimum voltage that > satisfies all the requests that the consumers have made. The consumer > which requires 1.1V will have requested 1.1V up to, say, 3.3V. The > consumer that requested 1.3V will have requested, say, 1.3-1.8V and > let's say the machine constraints will allow at least these ranges. > 1.3V is the lowest voltage that hits all the constraints, but it's still > lower than any of the maxima. > Aah. I get it now. >>> This was actually a feature of the regulator API when originally >>> proposed, it got dropped for ease of review but there's some remanants >>> of this in the code so it shouldn't be hard to resurrect. Whenever a >>> voltage was set the code stored the range on the consumer then iterated >>> over all consumers applying their ranges plus the machine constraints >>> rather than just using the immediate value. > >> I noticed some of the remnants. But I'm not sure I follow what you >> are saying. What range would the core actually propagate to the >> driver? The minimum min_uV and the maximum max_uV? We need the core >> to propagate the maximum min_uV and the maximum max_uV. > > No, it'd be the maximum min_uV and the minimum max_uV - this is already > happening when the constraints from the machine are applied, it'd just > be applying a wider set of constraints. In principle all we need to do > is remember the voltage constraints that individual consumers set and > then iterate over all the enabled consumers when one of them changes its > range (or is enabled/disabled) instead of just taking the immediate > values from the consumer. Got it. Only remaining question I have is if the aggregation of multiple consumer constraints should be the default (and only) behavior. Or should we introduce a new flag to the regulator_constraints structure that tells the core to aggregate consumer voltages constraints? -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regulator voltage aggregation
On Tue, Aug 17, 2010 at 12:33:33PM -0700, Bobby Crabtree wrote: > Mark Brown wrote: > > It's unlikely that the highest voltage would ever be the best choice... > We do need the highest voltage. Let's say we have two consumers > (A and B). Both require 1.3V for "normal" operations. Then let's > say that consumer A can save power by reducing the voltage to 1.1V > (but it doesn't require 1.1V). If the core were to immediately apply > 1.1V, then the 1.3V requirement of consumer B would not be satisfied. That's not the highest voltage, that's the minimum voltage that satisfies all the requests that the consumers have made. The consumer which requires 1.1V will have requested 1.1V up to, say, 3.3V. The consumer that requested 1.3V will have requested, say, 1.3-1.8V and let's say the machine constraints will allow at least these ranges. 1.3V is the lowest voltage that hits all the constraints, but it's still lower than any of the maxima. When you've got multiple things specifying a voltage constraint you need to apply the most restrictive combination of constraints but it still makes sense to pick the minimum voltage we can deliver from the range that's left after doing that. > > This was actually a feature of the regulator API when originally > > proposed, it got dropped for ease of review but there's some remanants > > of this in the code so it shouldn't be hard to resurrect. Whenever a > > voltage was set the code stored the range on the consumer then iterated > > over all consumers applying their ranges plus the machine constraints > > rather than just using the immediate value. > I noticed some of the remnants. But I'm not sure I follow what you > are saying. What range would the core actually propagate to the > driver? The minimum min_uV and the maximum max_uV? We need the core > to propagate the maximum min_uV and the maximum max_uV. No, it'd be the maximum min_uV and the minimum max_uV - this is already happening when the constraints from the machine are applied, it'd just be applying a wider set of constraints. In principle all we need to do is remember the voltage constraints that individual consumers set and then iterate over all the enabled consumers when one of them changes its range (or is enabled/disabled) instead of just taking the immediate values from the consumer. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regulator voltage aggregation
Mark Brown wrote: > On Tue, Aug 17, 2010 at 11:06:10AM -0700, Bobby Crabtree wrote: >> I'm looking to upstream a new feature in which the regulator core >> aggregates voltage requests from multiple consumers and applies the best >> fitting voltage (e.g. max voltage) to a shared supply. The core would > > It's unlikely that the highest voltage would ever be the best choice... > We do need the highest voltage. Let's say we have two consumers (A and B). Both require 1.3V for "normal" operations. Then let's say that consumer A can save power by reducing the voltage to 1.1V (but it doesn't require 1.1V). If the core were to immediately apply 1.1V, then the 1.3V requirement of consumer B would not be satisfied. >> recompute the best fitting voltage when a consumer requests a voltage >> change or requests to enable/disable the regulator (similar logic to >> DRMS). > >> The reason we need this feature is for power savings. It would allow two >> or more consumers to "vote" on a voltage that's lower than the normal >> operating voltage. > > This was actually a feature of the regulator API when originally > proposed, it got dropped for ease of review but there's some remanants > of this in the code so it shouldn't be hard to resurrect. Whenever a > voltage was set the code stored the range on the consumer then iterated > over all consumers applying their ranges plus the machine constraints > rather than just using the immediate value. > I noticed some of the remnants. But I'm not sure I follow what you are saying. What range would the core actually propagate to the driver? The minimum min_uV and the maximum max_uV? We need the core to propagate the maximum min_uV and the maximum max_uV. >> 1. Introduce a new API: > >> int regulator_set_optimum_voltage(struct regulator *regulator, >> int min_uV, int max_uV); > > Why would you want to do this? This is just the same arguments as the > standard regulator_set_voltage() call and if we're ever setting anything > other than the optimal voltage we probably ought to just stop doing > that. > "Optimum" was a bad choice of words. Seems that a new API isn't preferred, so let's scrap this option. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regulator voltage aggregation
On Tue, Aug 17, 2010 at 07:28:06PM +0100, Alan Cox wrote: > O> int regulator_set_optimum_voltage(struct regulator *regulator, > > int min_uV, int max_uV); > Pedantic hat on - how can it be optimum if its a range ? (and an > adjective but that is really pedantic) ;)) > Surely it's not the optimal value, it's the range at which it works at > all you are defining (between off, and escaping smoke). > set_voltage_range() sounds rather more natural to me. The regulator API always specifies voltages in ranges, picking the lowest possible voltage from the range. One reason for this is that it allows us to finesse the mismatches between the fixed steps that regulators offer and the requirements of consumers - we don't needlessly fail to set a voltage due to a few milivolts difference that the consumer doesn't care about. The other reason is that it maps very well onto a lot of applications which do have fairly wide acceptable ranges. For things like DVFS lowering the frequency will typically reduce the minimum voltage required by the device but will not affect the maximum voltage it can tolerate so we allow the driver to specify the full range it can operate at and then deliver the maximum power saving we can within the constraints of the system. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regulator voltage aggregation
On Tue, Aug 17, 2010 at 11:06:10AM -0700, Bobby Crabtree wrote:
> I'm looking to upstream a new feature in which the regulator core
> aggregates voltage requests from multiple consumers and applies the best
> fitting voltage (e.g. max voltage) to a shared supply. The core would
It's unlikely that the highest voltage would ever be the best choice...
> recompute the best fitting voltage when a consumer requests a voltage
> change or requests to enable/disable the regulator (similar logic to
> DRMS).
> The reason we need this feature is for power savings. It would allow two
> or more consumers to "vote" on a voltage that's lower than the normal
> operating voltage.
This was actually a feature of the regulator API when originally
proposed, it got dropped for ease of review but there's some remanants
of this in the code so it shouldn't be hard to resurrect. Whenever a
voltage was set the code stored the range on the consumer then iterated
over all consumers applying their ranges plus the machine constraints
rather than just using the immediate value.
> 1. Introduce a new API:
> int regulator_set_optimum_voltage(struct regulator *regulator,
> int min_uV, int max_uV);
Why would you want to do this? This is just the same arguments as the
standard regulator_set_voltage() call and if we're ever setting anything
other than the optimal voltage we probably ought to just stop doing
that.
> 2. Add a flag to the regulation_constraints structure and reuse the
> existing regulator_set_voltage API.
> struct regulation_constraints {
> ...
> unsigned aggregate_uV:1;
> ...
> };
> Does this sound like a reasonable feature? And if so, are there any
> preferences as to how the feature is implemented and exposed?
If we were going to add something for this it should be a capability,
however I don't think there's any need to add anything to the API since
this is the only sane interpretation of allowing voltage changes on a
regulator with more than one consumer.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regulator voltage aggregation
O> int regulator_set_optimum_voltage(struct regulator *regulator, > int min_uV, int max_uV); Pedantic hat on - how can it be optimum if its a range ? (and an adjective but that is really pedantic) ;)) Surely it's not the optimal value, it's the range at which it works at all you are defining (between off, and escaping smoke). set_voltage_range() sounds rather more natural to me. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
regulator voltage aggregation
I'm looking to upstream a new feature in which the regulator core
aggregates voltage requests from multiple consumers and applies the best
fitting voltage (e.g. max voltage) to a shared supply. The core would
recompute the best fitting voltage when a consumer requests a voltage
change or requests to enable/disable the regulator (similar logic to
DRMS).
The reason we need this feature is for power savings. It would allow two
or more consumers to "vote" on a voltage that's lower than the normal
operating voltage.
I've got a couple implementations in mind.
1. Introduce a new API:
int regulator_set_optimum_voltage(struct regulator *regulator,
int min_uV, int max_uV);
2. Add a flag to the regulation_constraints structure and reuse the
existing regulator_set_voltage API.
struct regulation_constraints {
...
unsigned aggregate_uV:1;
...
};
Does this sound like a reasonable feature? And if so, are there any
preferences as to how the feature is implemented and exposed?
Bobby Crabtree
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] input: mouse: add qci touchpad driver
Hi Neil, On Aug 17, 2010, at 10:14 AM, Neil Leeder wrote: On 8/13/2010 8:54 PM, Dmitry Torokhov wrote: Also it is not a simple coincidence that to enable device you send 0xf4 to it (which is PSMOUSE_CMD_ENABLE - standard PS/2 command). This tends to suggest that interface is not actually hidden and that the device (touchpad) could be replaced with other kinds of devices. Anyway, please try the driver (you may need to hardcode the IRQ trigger type for now) and see if psmouse is able to talk to the touchpad. If it is then serio is the proper solution. Dmitri, I fixed one line in the wpce775x_serio driver which looked like a typo - hope I got that right: for (i = 0; i < count; i++) -serio_interrupt(ps2if->serio, ps2if->data_in[1], 0); +serio_interrupt(ps2if->serio, ps2if->data_in[i], 0); } Yep, that was a typo. I tried running with psmouse but it didn't work. The touchpad was never detected as a synaptics touchpad. I looked at the dataflow from the device and it wasn't responding to the commands that synaptics_detect() was sending it. It eventually showed up as an unknown logitech mouse. That suggests that the device responds to at least basic PS/2 queries. I can see data being passed through the serio driver but the logitech driver can't process it. What about loading psmouse module with proto=bare? Could you also dump the data received from touchpad during probing? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] input: mouse: add qci touchpad driver
On 8/13/2010 8:54 PM, Dmitry Torokhov wrote: Also it is not a simple coincidence that to enable device you send 0xf4 to it (which is PSMOUSE_CMD_ENABLE - standard PS/2 command). This tends to suggest that interface is not actually hidden and that the device (touchpad) could be replaced with other kinds of devices. Anyway, please try the driver (you may need to hardcode the IRQ trigger type for now) and see if psmouse is able to talk to the touchpad. If it is then serio is the proper solution. Dmitri, I fixed one line in the wpce775x_serio driver which looked like a typo - hope I got that right: for (i = 0; i < count; i++) - serio_interrupt(ps2if->serio, ps2if->data_in[1], 0); + serio_interrupt(ps2if->serio, ps2if->data_in[i], 0); } I tried running with psmouse but it didn't work. The touchpad was never detected as a synaptics touchpad. I looked at the dataflow from the device and it wasn't responding to the commands that synaptics_detect() was sending it. It eventually showed up as an unknown logitech mouse. I can see data being passed through the serio driver but the logitech driver can't process it. -- Neil -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Keyboard for HTC-Dream
>Matrix driver should be capable of doing that... and look into >staging, IIRC the driver is there. Hmm. Ok. Thx! Then it's just not initialised on bootup? Because there's nothing happening, when I'm try'n to type root into "login:" (I know dumb error description... Sry,) Well then I'll tinker around, as soon as all my examina are done. (7 examina. All two days I write one. => 3 weeks no time) Thx a lot for your help! I'll report results here, when I've got some. leviathan signature.asc Description: This is a digitally signed message part.
Re: [PATCH v4] arm: msm: Add MSM IOMMU support.
On 8/16/2010 11:32 AM, Konrad Rzeszutek Wilk wrote:
I did a very brief look.
+ dmac_flush_range(fl_table, fl_table + SZ_16K);
+
+ for (i = 0; i< 4096; i++)
Can you use a #define for the 4096? Will that value ever change?
I suppose a #define can be used, but this is a HW-specific number that
will never ever change.
+ if ((fl_table[i]& 0x03) == FL_TYPE_TABLE) {
+ void *sl_table = __va(fl_table[i]& 0xFC00);
Does it make sense to define say:
#define MASK_XX (x) x& 0xFC00
and
#define MASK_XY (x) x& 0x
and use those instead of these hard-coded values?
I guess so.. again, HW specific.
+ priv->pgtable = (unsigned long *)__get_free_pages(GFP_KERNEL, 2);
Ugh. Can you use get_order(SZ_16K) instead?
+ /* Invalidate context TLB */
+ SET_CTX_TLBIALL(base, ctx, 0);
+ SET_V2PPR_VA(base, ctx, va>> 12);
Hmm, PAGE_SHIFT can't be used? Or some other #define?
I guess I can use the IOMMU PA shift. PAGE_SHIFT is not appropriate here
because that is MMU-specific.
I can put out a v5 early next week.
Thanks
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
